The “2.0” thing is getting a bit tiresome. It’s a common term our industry uses to indicate that something could be a game changer, but can we be a bit more innovative and creative?
In the case of multicloud, the 1.0 version, which has emerged through the use of plural public cloud brands for most enterprises, the enterprise typically relies on a proprietary CMP (cloud management platform) or CSB (cloud services broker) to manage many cloud-native services using a single interface or abstraction, also known as a “single pane of glass.”
This is the way most multicloud deployments are managed today. If you did not have a CMP or a CSB, you would have to deal with each cloud-native service using whatever cloud-native console that the public cloud vendor provided you.
Thus, if you had three public clouds in your multicloud, you would need three different interfaces and three types of skill sets. It’s hard to operationalize that longer term—too much complexity.
The “2.0 version” that’s emerging now is to move to a different type of multicloud: one that uses federated Kubernetes as the means to manage containerized applications and data that run on different public cloud providers but are aware of each other.
What’s helpful around the federated Kubernetes approach is that this architecture makes it easy to deal with multiple clusters running on multiple clouds. This is from using two major building blocks. First is the capability of syncing resources across clusters. As you may expect, this would be the core challenge for those deploying multicloud Kubernetes. Mechanisms within Kubernetes can automatically sync deployments on plural clusters, running on many public clouds. Second is intercluster discovery. This means the capability of automatically configuring DNS servers and load balancers with backends supporting all clusters running across many public clouds.
The benefits of leveraging multicloud/federated Kubernetes include high availability, considering you can replicate active/active clusters across multiple public clouds. Thus, if one has an outage, the other can pick up the processing without missing a beat.
Also, you avoid that dreaded provider lock-in. This considering that Kubernetes is the abstraction layer that’s able to remove you from the complexities and native details of each public cloud provider. Thus, it replaces both CSBs and CMPs.
If one cloud provider goes away or raises prices too much, no biggy. You just go with other cloud providers in the market. Public cloud providers become commodity cluster processors. Also, keep in mind Kubernetes is open source.
There is no magic bullet here. Indeed, those who set up Kubernetes on premises or in the cloud still have a very complex job. Setting up Kubernetes using a federated architecture will even be more complex.
However, the number of tools and best practices supporting this approach are beginning to emerge. Moreover, I’m seeing more federated Kubernetes skills in the marketplace. Indeed, this could be a better way to do multicloud. I’m certainly going to be one of those leading the charge to see where this goes.