If you don’t like something, redefine it. If you’d like something different, redefine things to suit your fancy. OK, that sounds like basic marketing, but it also has a tendency to confuse complex issues, as well as buyers who face them. We’re seeing this in the area that’s absolutely the most important thing in IT today, the cloud.
Fundamentally, what is a “cloud”? The majority of enterprises say that a cloud is a public computing service, something that offers Infrastructure-, Platform-, or Software-as-a-Service. That’s synonymous with “public cloud”, in other words. What is “multi-cloud”? It’s having multiple public cloud providers. “Hybrid cloud” is a combination of public cloud and data center. All these definitions are supported by almost three-quarters of the enterprise IT planners I’ve been in contact with over the last six months.
Now, in February of 2021, we’re seeing some weakening of these definitional norms. One example is that the term “multi-cloud” is increasingly applied to hybrid clouds, and I think this shift can be attributed to attempts to make “multi-cloud” marketing relevant to hybrid clouds (which are almost universal) versus multi-public-cloud use (which is way less common than many companies say it is).
There’s a lot of popular focus on multi-cloud, generated in no small part by media stories, and a lot of it is based on the “locked in” or “single point of failure” arguments. The largest driver of multi-cloud has never been that, it’s been one or both of two factors. The first is that all public clouds don’t cover all geographies well, so somethings users had to hybridize. The largest cloud providers now cover pretty much the same geographies, so this is less a factor. The second is that all clouds don’t offer the same features, and some applications need a specific feature set. This is not only still the case, but a growing one. Cloud providers, in some areas, are diverging in features more rapidly than a year ago.
The feature differences between public clouds are actually a voice speaking against multi-cloud, though. Early public cloud use was really a kind of re-hosting push, moving something that ran in the data center into the cloud. IaaS services in the cloud, analogous to VM usage in the data center, is pretty universal, meaning that there are no cloud features that impact development and execution, only operations. Today, over 80% of new cloud applications are written for the cloud, and since every cloud provider offers at least slightly different implementation of features, if not different features, these applications are not portable.
This means that the largest number of “multi-clouds” emerging, if we accept the old multiple-public-clouds definition, are created by application-specific cloud needs. That’s important because these multi-clouds are less likely to be sharing things between clouds; the applications are separate. It also means that the relationship between the cloud(s) and the data centers—the hybrid cloud—is really important, and that relationship is as much operational as programmatic.
A cloud is a resource pool abstracted to look like a computer, one that might be bare (IaaS), have OS and middleware (PaaS), or run an application component set (SaaS). That’s fine, but what runs on these platforms? An application or an application component has to deploy on something. What? The old answer was “VMs”, but the new answer, increasingly, is “containers”, and that introduces our second terminological shift.
Is a “container” a “cloud”? Not unless we change how we define clouds, but that’s not necessarily a barrier. Logically, though, containers relate to things that you host, and clouds to what you host on. Moving to containers doesn’t mean the same thing as moving to the cloud, and formatting applications or components into containers doesn’t make them “cloud-native”, despite claims from many in the NFV community to the contrary.
A container packages applications and dependent elements (like databases) into a deployable unit that’s substantially infrastructure-independent because everything that’s needed for deployment is in the container. Containers, and Kubernetes orchestration of container deployments, is becoming a standard approach both for the data center and for the cloud. Thus, over time, both public cloud and data center are becoming container hosting options. So, according to some vendors and stories/reports, a hybrid cloud is a premises container “cloud” and one or more public clouds.
What’s really happening here is that containers have become a deployment option that works across both cloud and data center. Operationally speaking, this could be a step toward unifying the cloud(s) and the data center, but remember that public cloud services are a combination of hosting (including managed container or Kubernetes services) and those cloud-provider PaaS-like web service features. Those features may make a given container/component non-portable.
This explains why some of the initiatives of the public cloud providers to support user-supplied edge hosting are, or include, a way to extend the web-service framework of the cloud provider to the user edge. One could expect that these same sorts of initiatives could extend cloud-provider services into the data center, which would then mean that the containers would be fully portable across that boundary. Since these hybrid-edge facilities of cloud providers are specific to each provider, using them would reduce public cloud portability.
This creates, in a sense, a layered model of hybrid application deployment. At the top of the layer stack are the application/component elements. These have a relationship with one or more “platform-layer” elements, representing the web services or middleware services that are not universally available. Those, in turn, ride on the container layer, which rides on “hosting” layer elements representing each public cloud and the data center(s).
This also explains why “Kubernetes federation” tools like Google’s Anthos are so much in the news. In Kubernetes, the general rule is that public clouds and data centers are independent domains (clusters), so some form of cross-cluster federation is needed to coordinate anything that has to cross the boundaries. It’s perfectly possible to create static bridges between clusters without federating them, but if you want to be able to deploy across the cluster boundaries, you’ll need a federation tool like Anthos. Google has been working hard to get Anthos supported on all public clouds, and of course it’s already available for data center deployments.
I think that containers are a logical evolution of server virtualization, and that they’d have grown in popularity with or without collateral interest in public cloud services. Public cloud does seem to make them inevitable, though, and there has certainly been some cross-influencing between cloud and container. That shouldn’t encourage us to conflate the two, in particular as we’re discussing “cloud-native”. There are a lot of things needed to convert a “container” strategy for the cloud to cloud-native, and to miss them is to risk a lot of the cloud-native benefits.