Introducing the main players in the field

We have been talking about public and private clouds. Although it's probably clear what we commonly understand by these terms, it's probably a good idea to have a very clear definition of both. We adhere to the definition as presented on the Microsoft website: the public cloud is defined as computing services offered by third-party providers over the public internet, making them available to anyone who wants to use or purchase them. The private cloud is defined as computing services offered either over the internet or a private internal network and only to select users instead of the general public. There are many more definitions, but these serve our purpose very well.

Public clouds

In the public cloud, the best-known providers are AWS, Microsoft Azure, GCP, and public clouds that have OpenStack as their technological foundation. An example of the latter one is Rackspace. These are all public clouds that fit the definition that we just gave, but there are also some major differences.

AWS and Azure have a common starting ground, however – both platforms evolved from making storage publicly available over the internet. At AWS, it started with a storage service called the Simple Storage Solution, or S3. Azure also started off with storage.

AWS, Azure, and GCP all offer a wide variety of managed services to build environments, but they all differ very much in the way you apply the technology. In short: the concepts are more or less alike, but under the hood, these are completely different beasts. It's exactly this that makes managing multi-cloud solutions complex.

There are many more public cloud offerings, but these are usually not fit for all purposes. Major software manufacturers including Oracle and SAP also have public cloud offerings available, but these are really tailored to hosting the specific software solutions of these companies. Nonetheless, they are part of the multi-cloud landscape, since a lot of enterprises use, for instance, enterprise resource planning software from SAP and/or data solutions from Oracle. These companies are also shifting their solutions more and more to fully scalable cloud environments, where they need to be integrated with systems that reside on premises or in other clouds. In some cases, these propositions have evolved to full clouds, such as OCI by Oracle. Over the course of this book, we will address these specific propositions, since they do require some special attention. Just think of license management, as an example.

In this book, we will mainly focus on the major players in the multi-cloud portfolio, as represented in the following diagram:

Figure 1.3 – An example multi-cloud portfolio: the main players

Note

We have been discussing Microsoft Azure, AWS, GCP, and OpenStack as the main public cloud platforms. As said, there are more platforms, but in this book, we are limiting our discussions to the main players in the field and adhering to the platforms that have been identified as leaders by Gartner and Forrester.

So far, we've looked at the differences between private and public clouds and the main players in the public cloud domain. In the next section, we will focus on the leading private propositions for enterprises.

Private clouds

Most companies are planning to move, or are actually in the midst of moving, their workloads to the cloud. In general, they have a selected number of major platforms that they choose to host the workloads: Azure, AWS, GCP, and that's about it. Fair enough, there are more platforms, but the three mentioned are the most dominant ones, and will continue to be so throughout the forthcoming decades, if we look at analysts' reports.

As we already found out in the previous paragraphs, in planning for and migrating workloads to these platforms, organizations also discover that it does get complex. Even more important, there are more and more regulations in terms of compliance, security, and privacy that force these companies to think twice before they bring our data onto these platforms. And it's all about the data, in the end. It's the most valuable asset in any company – next to people.

The solution: instead of bringing data to the cloud, we're taking the cloud to the data – again. Over the last few years, we've seen a new movement where the major cloud providers have started stepping into domains where other companies were still traditionally dominant; companies such as storage providers and system integrators. The new reality is that public cloud providers are shifting more and more into the on-premises domain.

In the private cloud, VMware seems to be the dominant platform, next to environments that have Microsoft with Hyper-V technology as their basis. Yet, Microsoft is pushing customers more and more to consumption in Azure and where systems need to be kept on premises, they have a broad portfolio available with Azure Stack, which we will discuss in a bit more detail later in this chapter.

Especially in European governmental environments, OpenStack still seems to do very well, to avoid having data controlled or even viewed by American-based companies. However, the adoption and usage of OpenStack seems to be declining.

In this chapter, we will look briefly at both VMware and OpenStack as private stack foundations. After that, we'll have a deeper look at AWS Outposts and Google Anthos. Basically, both propositions extend the public clouds of AWS and GCP into the privately owned data center. Outposts is an appliance that comes as a preconfigured rack with compute, storage, and network facilities. Anthos by Google is more a set of components that can be utilized to specifically host container platforms in on-premises environments using the Google Kubernetes Engine (GKE). Finally, in this chapter, we will have a look at the Azure Stack portfolio.

VMware

In essence, VMware is still a virtualization technology. It started off with the virtualization of x86-based physical servers, enabling multiple virtual machines on one physical host. Later, VMware introduced the same concept to storage with vSAN (virtualized SAN) and NSX (network virtualization and security) that virtualizes the network, making it possible to adopt micro-segmentation in private clouds. The company has been able to constantly find ways to move along with the shift to the cloud – as an example, by developing a proposition together with AWS where VMware private clouds can be seamlessly extended to the public cloud.

Today, VMware is also a strong player in the field of containerization with Pivotal Kubernetes Services (PKS) and container orchestration with Tanzu Mission Control. Over the last few years, the company has strengthened its position in the security domain, again targeting the multi-cloud stack. Basically, VMware is trying to become the spider in the multi-cloud web by leveraging solutions on top of the native public cloud players.

OpenStack

There are absolutely benefits to OpenStack. It's a free and open source software platform for cloud computing, mostly used as IaaS. OpenStack uses KVM as its main hypervisor, although there were more hypervisors available for OpenStack. It was—and still is, with a group of companies and institutions—popular since it offered a stable, scalable solution while avoiding vendor lock-in on the major cloud and technology providers. Major integrators and system providers such as IBM and Fujitsu adopted OpenStack in their respective cloud platforms, Bluemix and K5 (decommissioned internationally in 2018).

However, although OpenStack is open source and can be completely tweaked and tuned to specific business needs, it is also complex, and companies find it cumbersome to manage. Most of these platforms do not have the richness of solutions that, for example, Azure, AWS, and GCP offer to their clients. Over the last few years, OpenStack seems to have lost its foothold in the enterprise world, yet it still has a somewhat relevant position and certain aspects are therefore considered in this book.

AWS Outposts

Everything you run on the AWS public cloud, you can now run on an appliance, including Elastic Compute Cloud (EC2), Elastic Block Store (EBS), databases, and even Kubernetes clusters with Elastic Kubernetes Services (EKS). It all seamlessly integrates with the virtual private cloud (VPC) that you would have deployed in the public cloud, using the same APIs and controls. That is, in a nutshell, AWS Outposts: the AWS public cloud on premises.

One question might be what this means for the VMC (VMware on Cloud) on AWS proposition that both VMware and AWS have in their portfolio.

Note

You can buy VMConAWS through VMware or through AWS.

VMConAWS actually extends the private cloud to the public cloud, based on HCX by VMware. VMware uses bare metal instances in AWS to which it deploys vSphere, vSAN storage, and NSX for software-defined networking.

You can also use AWS services on top of the configuration of VMConAWS through integration with AWS. Outposts works exactly the other way around: bringing AWS to the private cloud.

Google Anthos

Anthos brings Google Cloud – or more accurately, the Google Kubernetes Engine – to the on-premises data center, just as Azure Stack does for Azure and Outposts for AWS, but it focuses on the use of Kubernetes as a landing platform, moving and converting workloads directly into containers using GKE. It's not a standalone box, such as Azure Stack or Outposts. The solution runs on top of virtualized machines using vSphere, and is more a PaaS solution. Anthos really accelerates the transformation of applications to more cloud-native environments, using open source technology including Istio for microservices and Knative for the scaling and deployment of cloud-native apps on Kubernetes.

Tip

More information on the specifics of Anthos can be found at https://cloud.google.com/anthos/gke/docs/on-prem/how-to/vsphere-requirements-basic.

Azure Stack

And then there is the Azure Stack portfolio with Stack HCI, Hub, and Edge.

The most important feature of Azure Stack Hyperconverged Infrastructure (HCI) is that it can run "disconnected" from Azure. To put it very simply: HCI works like the commonly known branch office server. Basically, HCI is a box that contains compute power, storage, and network connections. The box holds Hyper-V-based virtualized workloads that you can manage with Windows Admin Center. So, why would you want to run this as Azure Stack then? Well, Azure Stack HCI also has the option to connect to Azure services, such as Azure Site Recovery, Azure Backup, and Azure Monitoring.

It's a very simple solution that only requires Microsoft-validated hardware, the installation of Windows Server 2019 Datacenter Edition, plus Windows Admin Center and optionally an Azure account to connect to specific Azure cloud services.

Pre-warning: it might get a bit complicated from this point onward: Azure Stack HCI is also the foundation underneath Azure Stack Hub (side note: all Azure products are based on Windows Server 2019). Yet, Hub is a different solution. Whereas you can run Stack HCI standalone, Hub as a solution is integrated with the Azure public cloud – and that's really a different ballgame. It's the reason why you can't upgrade HCI to Hub.

Azure Stack Hub is really the on-premises extension of the Azure public cloud. Almost everything you can do in the public cloud of Microsoft, you could also deploy on Hub: from VMs to apps, all managed through the Azure portal or even PowerShell. It all really works like Azure, including things such as configuring and updating fault domains. Hub also supports having an availability set with a maximum of three fault domains to be consistent with Azure. This way you can create high availability on Hub just as you would in Azure.

The perfect use case for Hub and the Azure public cloud would be to do development on the public cloud and move production to Hub, should apps or VMs need to be hosted on premises for compliance reasons. The good news is that you can configure your pipeline in such a manner that development and testing can be executed on the public cloud and run deployment of the validated production systems, including desired state configuration, on Hub. This will work fine since both entities of the Azure platform use the Azure resource providers in a consistent way.

There are a few things to be aware of, though. The compute resource provider will create its own VMs on Hub. In other words: it does not copy the VM from the public cloud to Hub. The same applies to network resources. Hub will create its own network features such as load balancers, vNets, and network security groups (NSGs). As for storage, Hub allows you to deploy all storage forms that you would have available on the Azure public cloud, such as blob, queue, and tables. Obviously, we will discuss all of this in much more detail in this book, so don't worry if a number of terms don't sound familiar at this time.

One last Stack product is Stack Edge. Previously, Microsoft sold Azure Stack Edge as Data Box: it's still part of the Data Box family. Edge makes it easy to send data to Azure. As Microsoft puts it on their website: Azure Stack Edge acts as a network storage gateway and performs high-speed transfers to Azure. The best part? You can manage Edge from the Azure portal. Sounds easy, right?

Hold on. There's more to it. It's—again—called Kubernetes. Edge runs containers to enable data analyses, perform queries, and filter data at edge locations. Therefore, Edge supports Azure VMs and Azure Kubernetes Services (AKS) clusters that you can run containers on. Edge, for that matter, is quite a sophisticated solution since it also integrates with Azure Machine Learning (AML). You can build and train machine learning models in Azure, run them in Azure Stack Edge, and send the datasets back to Azure. For this, the Edge solution is equipped with the FPGAs (Field Programmable Gate Arrays) and GPUs (Graphics Processing Units) required to speed up building and (re)training the models.

Having said this, the obvious use case comes with the implementation of data analytics and machine learning where you don't want raw data to be uploaded to the public cloud straight away.

Azure Arc

There's one more feature that needs to be discussed at this point and that's Azure Arc, launched at Ignite 2019. Arc allows you to connect non-Azure machines to Azure and manage these non-Azure workloads as if they were fully deployed on Azure itself.

If you want to connect a machine to Arc, you need to install an agent on that machine. It will then get a resource ID and become part of a resource group in your Azure tenant. However, this won't happen until you've configured some settings on the network side of things and registered the appropriate resource providers (Microsoft.HybridCompute and Microsoft.GuestConfiguration). Yes, this does require proficient PowerShell skills. If you perform the actions successfully, then you can have non-Azure machines managed through Azure. In practice, this means that you can add tagging and policies to these workloads. That sort of defines the use case: managing the non-Azure machines in line with the same policies as the Azure machines. These do not necessarily have to be on premises. That's likely the best part of Arc: it also works on VMs that are deployed in AWS.

With that last remark on Arc, we've come to the core of the multi-cloud discussion, and that's integration. All of the platforms that we studied in this chapter have advantages, disadvantages, dependencies, and even specific use cases. Hence, we see enterprises experimenting with and deploying workloads in more than one cloud. That's not just to avoid cloud vendor lock-in: it's mainly because there's not a "one size fits all" solution.

In short, it should be clear that it's really not about cloud first. It's about getting cloud fit, that is, getting the best out of an ever-increasing variety of cloud solutions. This book will hopefully help you to master working with the mix of these solutions.