Google open sourced Kubernetes in 2014 as a Trojan horse—bringing developers around on its way of computing before ultimately bringing them onto its cloud—but don’t be surprised to see Microsoft as the company with the most complete Kubernetes vision.
On Wednesday, Microsoft took the important step of joining the Cloud Native Computing Foundation
—the open source foundation set up originally as an independent home to Kubernetes, and now to many more projects—and the seemingly smaller, but possibly more important, step of announcing a new service called Azure Container Instances
(ACI). Microsoft has been doing a lot in the Kubernetes space for at least the last year (it hired Kubernetes co-creator Brendan Burns last July), which makes it joining the CNCF important mainly in the sense of solidifying that commitment. Oh, and leaving AWS as the only major cloud provider to not
be a member.
What’s remarkable about ACI is that Microsoft has taken the process of building and deploying containers—already a relatively simple process—and made it even simpler. They’re even billed by the second, which makes sense given very temporary nature of many containers. You can read more details on the specifics in the Microsoft blog post linked to above, and also here:
What I find most interesting, however, is that Azure Container Instances have nothing to do with Kubernetes out of the box. They’re just plain, old, individual Linux (and, soon, Windows) containers without an orchestrator. This could end up being a great way to get customers started experimenting with running containers and microservices on Azure, without the overhead of configuring clusters and going all Kubernetes out of the gates.
However, Microsoft has built a connector that allows ACIs to be launched and managed directly from Kubernetes. The idea is users will run long-running containers on Azure VMs, and short-lived containers on ACIs, and use Azure Container Service to manage the whole thing.
The ACI service comes on the heels of some significant open source activity by Microsoft, too. In April, it acquired Kubernetes startup Deis
, which was responsible for some important projects, such as Helm, aiming to simplify the creation of Kubernetes services. And then, in May, Microsoft (with help from its new team of Deis engineers) released Draft
, an open source tool for converting existing applications into containerized ones running on Kubernetes.
It is, of course, premature to crown Microsoft the king of cloud Kubernetes when Google is still around. Google continues to work on Kubernetes and peripheral cloud-native projects
, and is more than capable of innovating commercially around its existing Google Container Engine service. But Microsoft has been making up for lost time and appears determined to have its name associated with Kubernetes just like Google’s already is.
If, as all signs suggest, Kubernetes becomes a common platform on which many future applications are going to be built, I think both companies like their odds of being able to compete very strongly in that space with differentiated services. The same could probably be said of IBM, which is actively involved in Kubernetes, but runs a markedly smaller cloud operation.
The odd man out is AWS, which would explains last week’s speculation that the world’s largest cloud provider is working on a Kubernetes service of its own
. If the world is indeed heading toward Kubernetes and cloud-native, even AWS can’t risk looking like an outsider or, worse, ceding those workloads to its blood rivals.
For more on Microsoft’s ambitions here, check out my podcast interviews with Brendan Burns and Gabe Monroy: