Lines Between Public, Private, Hybrid Cloud Architectures Are Blurring

One of the first things you learn when you’re learning about cloud computing is that there are three main types of cloud architectures: public, private and hybrid. Increasingly, however, this categorization no longer makes sense. Thanks to the introduction of new types of cloud services and deployment options, the lines separating public, private and hybrid cloud architectures have become quite blurry. Some days, I don’t think it even makes sense to think in terms of public vs. private vs. hybrid at all.

Public vs. Private vs. Hybrid Cloud Architectures: The Traditional Definition

Conventional approaches to defining public, private and hybrid cloud architectures focus on who owns the cloud infrastructure.

In a public cloud, end users host workloads on infrastructure owned by a public cloud provider, like Azure or AWS. In a private cloud, organizations deploy cloud services on infrastructure they own themselves. Hybrid cloud architectures include a mix of both types of infrastructure.

Traditionally, the ownership of cloud infrastructure also determined who was responsible for delivering cloud services under the different architectural models. Public cloud providers managed the cloud services, like AWS EC2 or S3, that ran on their infrastructure. In a private cloud, organizations were responsible for provisioning and managing their own services via a platform like OpenStack. Hybrid cloud architectures also typically relied on cloud services that organizations set up and managed themselves using a mix of public and private infrastructure, with public cloud services sometimes entering the mix. 

A New Approach to Defining Cloud Architectures

Today, this old way of thinking about the differences between cloud architectures makes increasingly less sense. Here’s why:

Public clouds can manage private infrastructure.

Probably the biggest change is the advent of frameworks like Azure Stack, Azure Arc and AWS Outposts. These frameworks make it possible to extend public cloud services into private data centers, and to manage those services using public cloud tools. You can do this as part of a hybrid architecture if you want, but you can also use these solutions solely within a private data center.

What that means is there’s nothing stopping you from deploying, say, a public cloud IaaS storage or compute service on your own servers inside your own on-premises data center without using public cloud infrastructure. Or, you could run a managed public cloud service, like Google Kubernetes Engine, in an on-premises data center.

In the past, this was not possible. You would have had to choose between using public cloud services on public cloud infrastructure or running a private cloud if you wanted to keep workloads on your own hardware. While hybrid architectures were also available, they didn’t involve using a public cloud vendor’s software services to deploy and manage workloads that ran on-premises.

To put this another way, you can now build a private cloud on private infrastructure using public cloud services and management tools.

Private cloud platforms can run on public clouds.

From the opposite perspective, you can also run private cloud services on public cloud infrastructure. For example, you can go and deploy OpenStack on AWS if you want.

Granted, there are fewer reasons for wanting to bring a private cloud platform onto public cloud infrastructure than there are for running public cloud services on private infrastructure. However, some logical use cases exist.

For example, if you choose to run OpenStack on AWS, maybe it’s because you prefer to use OpenStack’s IaaS services over those offered natively by AWS. Or, maybe you want to build an OpenStack private cloud that you’ll later migrate to your own data center. If you don’t have the on-premises infrastructure to host it, you could set it up on public cloud infrastructure first.

Hybrid cloud architectures and multi-cloud converge.

A third trend at play is the advent of what you could call “cloud abstraction” platforms that let you deploy workloads across as many infrastructures as you want, regardless of whether they are public or private. Google Anthos (which is based in part on Kubernetes) is the prime example, although you could achieve the same basic functionality by deploying just Kubernetes itself across multiple clouds.

You could refer to solutions like these as hybrid cloud platforms, or you could call them multi-cloud solutions. (Google applies both labels to Anthos.) The labels don’t really matter, and that’s exactly the point: By delivering the same cloud end user experience regardless of how the underlying infrastructure is architected, these platforms blur the lines between hybrid cloud and multi-cloud.

Rethinking Cloud Architecture Definitions

In short, the cloud computing landscape has changed remarkably in the past few years, as a result of new frameworks and platforms like Azure Stack and Arc, AWS Outposts and Google Anthos. You can now run public cloud services in a private data center, or across a range of different public clouds and on-prem infrastructures. You can run a private cloud on public cloud infrastructure. You can even deploy a framework like Anthos on top of OpenStack or VMware.

To be sure, not every organization is using next-generation cloud solutions like these. Many will stick with architectures that align cleanly with conventional definitions of public, private or hybrid cloud architectures for some time to come.

But, I suspect that this will gradually change, and that, five or 10 years from now, these terms will be used only in reference to architectural patterns associated with the early decades of cloud computing.

The future of the cloud lies in models that blend public, private and hybrid architectures together beyond recognition. What will matter most going forward is not who happens to own your infrastructure, but which framework--Azure Stack or Arc, Anthos, Outposts and the like--you use to run cloud services on it.