I thought they were all the same?

If you deal with cloud environments in your career, you've likely heard one, two, or all three of these phrases mentioned. In my experience, they are used interchangeably quite often. However, they are not actually interchangeable. Though the phrases are related they mean significantly different things, and the architectural choices you will need to make to adhere to any one of them are distinct.

They're really not? Let's see some definitions!

In the vein of 'The Giver', "Precision in language!" is key here. Before we can define each of these phrases, though, we need to define a few types of clouds, as well as a few examples of things that, while cloud-y, are NOT actually cloud environments.

Cloud Environments

Cloud environments are those which conform to the National Institute of Standards and Technology's (NIST) definition of cloud computing. According to this standard,

"Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction."

This definition is provided in Special Publication 800-145 and includes the following key criteria:

• On-demand self-service - a consumer is able to provision compute resources automatically and without human interaction with the service provider
• Broad network access - services and resources are available over the network and accessed through standard mechanisms such as cell phones, tablets, laptops, and worksations
• Resource pooling - the provider's compute resources are pooled to serve multiple consumers using a multi-tenant model; this also refers to location independence for the resources
• Rapid elasticity - resources can be provisioned and released elastically, often automatically, so that the resources appear to the consumer to be limitless
• Measured service - resource usage is monitored, controlled, and reported to the provider and the consumer

Great! Now we know what the definition of Cloud is. Let's look at the definitions of public and private clouds next:

Public Cloud

Public clouds are cloud services that can be used by multiple to many different clients/customers. These services are multi-tenant, meaning that each customer's use is isolated from other customers. Examples of public clouds include Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform, Alibaba Cloud, IBM Cloud, etc. There are many public cloud providers in the market today.

Private Cloud

Private clouds are cloud services that are used by a single client/customer. Typically, these are cloud environments that are set up in a private data center, with the hardware managed, secured, and monitored by the cloud environment owner. Examples of these would be an AWS Outpost deployed in a company datacenter and Azure Cloud Edge.

Other Clouds

You may have heard the term Community Cloud as an intermediate between public and private clouds. Community cloud is a subset of public, because it meets the qualities of the public clouds as defined above, but is only made available to a limited set of clients/customers. Examples of this would include Azure Federal, AWS GovCloud, or Google and T-Systems' German sovereign cloud.

Cloud-y Environments (but NOT cloud environments)

Each of the cloud environments mentioned above meet all of the NIST SP 800-145 definition requirements to be labeled as clouds. There are several other environments out there that meet some of the requirements but not all. These are not true clouds, though they do provide some of the benefits of a true cloud.

Virtualized Environments

Virtualized environments are often called private cloud, but they are rarely configured to meet all of the requirements and thus are most of the time not actually true clouds. Examples of virtualization systems include VM VSphere, Virtuozzo, Nutanix AHV, and SYSE Linux Enterprise Server. These environments generally allow for rapid provisioning and deprovisioning of compute resources and usually provide broad network access. But they are typically resource constrained and access to the ability to provision assets usually passes through system administrator gatekeepers due to the constraints.

Container Clusters

Containerized clusters, often managed using a tool like Rancher or OpenShift, are sometimes used to build in scalability and fault tolerance in deployed systems, but they are dependent upon the hardware they are deployed upon, which means they themselves are not cloud. Though deployment of software applications in container clusters can feel very cloudy the clusters and their management systems are not by themselves clouds.

Multi, Hybrid, and Agnostic definitions

Now that we know a few different types of clouds, let's look at a quick definition for the three phrases mentioned in the title:

Multi Cloud

Multi-cloud systems are systems that are deployed across two or more similar-type clouds. This would be a system that uses GCP and Azure, or Azure Federal and AWS GovCloud, or AWS Outpost and Azure Cloud Edge.

Hybrid Cloud

Hybrid cloud systems are systems that are deployed across two or more dissimilar cloud types. Examples of this would include AWS Outpost connected to Azure and AWS, or AWS GovCloud interfacing with an AWS Outpost. Hybrid cloud systems seek to use the best possible tools across their dissimilar cloud types, such as using Azure AD for their access management and Azure Cloud Edge for low-latency data processing.

Cloud Agnostic

Cloud-agnostic systems are systems that can be deployed across any mix of cloud environments because they don't care what they are deployed upon. These systems most typically do not use specific services from any given cloud environment unless an analogue service is available in other cloud environments. Typically the specific service in use is abstracted away through the use of tools such as Ansible, Terraform, Puppet, or Chef, so that the system doesn't need to know which cloud it is running on. As an example, a cloud-agnostic system might use AWS S3 and Azure Blob storage to store data, and that storage configuration is controlled by the Terraform script used to define the infrastructure.

Ok, so when would I use multi-cloud, hybrid cloud, or cloud agnostic architectures?

You can make an argument for using any of the three options for your system architecture in most cases. However, here are a few cases where one option is better than the others:

1. Hybrid cloud: If you need to combine capabilities hosted in your private cloud with global reach and low-latency. As an example, you need to do on-prem data preparation work using a system you already have set up in your private cloud environment before you send the data into a new machine learning model as training material, and ultimately deploy the trained model for your clients, located around the world, to use. Cost is important to consider, as is data latency and weight. Because you have an on-premises component you know that you cannot use a single cloud solution, so you must make a choice. What makes the most sense here? Most likely a hybrid cloud, with your data prep being done in your on-premises private cloud, and the models trained and deployed in a public cloud.
2. Multi-cloud: If you need to use specific services in a few different public cloud providers. As an example, your company currently uses Microsoft products such as the Office suite along with Microsoft AD, but some of your developed systems are using AWS' AI/ML services such as Lex, Transcribe, and Comprehend. You may decide to move the Azure AD, and integrate that with the AWS services you are using to provide your access controls. Multi-cloud allows you to choose the best-in-class solutions for your specific problem across cloud providers. Multi-cloud can result in higher cloud bills than hybrid or single cloud solutions.
3. Cloud agnostic: If you are unsure where your system will be deployed, or if you know you have a mix of environments that it will be deployed into. As an example, you have a proprietary in-house developed engineering application that your civil engineers use to enable them on the job. They need to be able to use the application whether in a city, in wilderness areas with no cell signal, or out of country at a variety of international locations. The application is standalone or can store things independently for extended periods of time, or perhaps is REQUIRED to execute without internet connectivity because of its use cases. It would make sense in this setting to design your application as a set of stateless microservices deployed into containers, which could then be deployed on a cloud environment, bare metal, or some combination of the two.

A quick takeaway

As always when designing system architectures, the optimal architecture will depend upon your customer's needs and wants. Take the time to talk with your customer and understand what is essential when beginning to design a new system. Try not to assume you know the right answer before you've considered the options. You may be surprised at the way you end up going!

What have your experiences been with respect to these three deployment architectures? Have you built multi-cloud systems? Hybrid? Agnostic? I've had the opportunity to use all three for various use cases in my job. There is value in each, and none of the three are perfect. I would love to hear from you!