Hybrid cloud, multi-cloud and hybrid multi-cloud are terms that are seeing increasing use within IT. So what are the differences between them and when should an organization select one over the other? 

Before diving into the emerging terminology, it's worth taking a moment to define "cloud" in the context of this discussion. A cloud could reasonably be defined as any IT infrastructure that is largely automated and has a self-service front-end that enables consumption of resources without requiring systems administrators to be involved in the provisioning process.

This broad definition of cloud would cover on-premises clouds, whether operated by the organization itself or managed by a service provider. It would all cover many off-premises hosted solutions offered by service providers as well as the big four public cloud providers (Microsoft Azure, Amazon Web Services, Google Cloud Platform and IBM Cloud).

When most people talk about the hybrid cloud, multi-cloud and hybrid multi-cloud, however, the "cloud" portion of the discussion is almost always exclusively the big four public clouds. In rare instances it will include some of the smaller service provider offerings.

Of course, these terms are largely marketing terms, so the actual meaning of the terms usually boils down to "whatever it is the vendor in question happens to be selling." IT practitioners will have a different take on the terminology, of course, and it is the technical view that's worth exploring. 

Hybrid Cloud 

The short version of a hybrid cloud is that it combines infrastructure which an organization directly controls and manages with a public cloud. The infrastructure controlled by the organization may be on-premises and owned by the organization. It may also be infrastructure rented from a service provider that lives in an off-site co-location facility that is simply managed in the same manner as on-premises infrastructure. 

From a practical standpoint, there are usually only two considerations in determining whether a given infrastructure counts as "not public cloud" enough to make discussing it as "hybrid" relevant. The first is the administrative overhead that one's organization has to put into managing that infrastructure, and the second is the shared or dedicated nature of the infrastructure. 

There are a lot of blurry lines around this definition. If one were to own and operate all aspects of a data center, including servers, switches, storage, hypervisors, guest operating systems, and so forth, this is clearly on-premises infrastructure. But what if one doesn't own or operate the servers, switches or storage?  

What if one engages a service provider for a fully operational VMware cluster, but this cluster was managed by the organization instead of a service provider? In this case, the organization is responsible for the hypervisor on up, while the service provider provides bare-metal servers, physical networking, and storage as a service. Traditional public cloud infrastructure as a service (IaaS) solutions typically provision at the virtual machine level, or provide specific services such as databases on demand. 

The question of how many layers the organization itself needs to be responsible for managing in order to qualify as the "on-premises" part of a hybrid cloud discussion is more than an esoteric bit of nomenclature. Regulatory compliance considerations may require that organizations have full control over some or even the entirety of their IT infrastructure. Alternately, regulatory regimes may only forbid shared infrastructure approaches, and thus be perfectly fine with service providers offering dedicated servers, networking, and storage in an automated and self-service fashion. 

Direct control over infrastructure means that one's organization must devote human resources to managing that infrastructure. It also means that one can completely instrument the infrastructure in question and more easily engage in industry-specific or otherwise esoteric IT endeavours. 

Clouds tend to be quite prescriptive about how they can be consumed, and much of the effort surrounding the hybrid cloud is related to either providing a unified Security Information and Event Management (SIEM) solution across both infrastructures, or ensuring that applications and services can easily move between the two infrastructures, despite the  "T-shirt sizing" of workloads that public cloud providers typically enforce. 

Multi-Cloud 

Multi-cloud discussions are quite different from hybrid cloud discussions. Multi-cloud typically excludes on-premises IT in any form, and also typically makes a series of assumptions about the "cloud-native" nature of the applications and services being managed. 

Public cloud providers encourage organizations to make their workloads "cattle." This contrasts with on-premises workloads, which are usually "pets." The pets versus cattle meme goes something like this: pets are loved, cherished, and given names. If pets get sick, you nurture them back to health. Cattle, on the other hand, are merely given numbers. If some cattle get sick, you put them down and replace them. 

The meme isn't entirely accurate – farmers to care for their ailing cattle just as they do their pets – but the underlying concept is easy to grasp. Cloud workloads are supposed to be composable: as much as possible the Operating System Environment (OSE), application, and application configuration are supposed to be defined in code. In this manner the workload can be created, destroyed and recreated from code easily, and as often as required. Only the data upon which the workload operates is sacred.

When workloads are composable they can (hypothetically) be moved from cloud to cloud so easily that this movement can be automated. There are an unlimited number of videos on YouTube with someone demonstrating exactly this using Kubernetes. 

Not all workloads can be made composable, and even fewer can be containerized and managed by Kubernetes. Public clouds are packed full of "pets" running on IaaS-provisioned VMs, or which are built not from a Git repo but from a custom template. 

In addition, some workloads rely on proprietary features of a given public cloud: machine learning, artificial intelligence and other Bulk Data Computational Analysis (BDCA) tools are common examples. BDCA tools offered by one of the big four cloud providers are likely to have an analogous offering at the other big public cloud providers. The proprietary nature of the APIs, however, means that a workload using facial recognition from Amazon won't necessarily be able to be packed up and moved to Azure. 

There are also numerous differences in how the public cloud providers offer up their networking, monitoring, alerting and security services. Even if one gets their workloads moving from cloud to cloud on command, there is plumbing to be done to make sure that one's organization can respond to compromise events and other outages. These are the discussions that surround "multi-cloud." 

Hybrid Multi-Cloud 

Hybrid multi-cloud is what it says on the tin. Take all of the complexity of hybrid cloud computing and smoosh it together with multi-cloud computing. Stir gently and the result is what systems administrators have been calling "IT" (sans fancy labels) for the past several decades. 

The only difference between the hybrid multi-cloud of today and the IT of a decade ago is that some percentage of the infrastructure is not owned or managed by one's organization. IT a decade ago would have been focused on the integration challenges relating to getting a bunch of IT appliances to play nice with one another, as well as with some 25-year-old DOS application that nobody ever found the time or money to replace. 

In the hybrid multi-cloud world systems administrators are instead trying to get their IT appliances to interoperate with public cloud providers as well as with a now 35-year-old DOS application that nobody ever found the time or money to replace. 

The buzzwords change, but the complexity of the networks, the need for in-depth application and data flow visibility, security that comes in flavors, and layers of analytics remain the same.