Kubernetes has won. Now the question is who will win Kubernetes.
Over the last year Kubernetes has won over the last hold outs, with VMware/Pivotal and Docker finally locking arms with the Google-spawned community darling. Docker founder Solomon Hykes tried to spin Docker's full support for Kubernetes as a non-event, reasoning that "Orchestration is a commodity, over time." No, it's not. Quite the opposite, in fact.
If anything, container orchestration—Kubernetes, in particular—is fast emerging as the operating system for the cloud. Just as various vendors spent years duking it out to become the dominant distribution of Linux, we're likely to see a similar scenario play out around Kubernetes. The only question is who will get to be the Red Hat Enterprise Linux of the data center operating system.
One big honking server
Hykes may not like to hear this, but other vendors aren't waiting around for Docker to update its keynote narratives. Red Hat's Daniel Riek, for example, has offered up OpenShift, its "distribution" of Kubernetes, as "the new Enterprise Linux." Going further, he dubbed OpenShift "an extension and superset of traditional RHEL," and therefore "the future cloud-native operating system."
Of course Riek could be wrong, and the analogy isn't perfect. It is, however, quite apt.
Putting aside Riek's contention that OpenShift is that OS, it's reasonable to posit, as analyst Krishnan Subramanian did, that "Kubernetes is...an ideal candidate to become the kernel for [the] Data Center / Application Infrastructure Operating System." Why? He explained:
Linux is the operating system for a single server. Google has made a clear case for Data Center as a Computer. If we consider Data Center to be a pooled resource unit that acts like a single computer, we need an operating system for the data center. There are many ways to build the datacenter operating system, either using virtual machines or containers. However, containers are fast emerging as the right candidate for application encapsulation because of its efficiency and portability advantages....
The Linux Kernel interfaces with the hardware using device drivers, manages processes, allocates resources and handles security. The kernel for Data Center / Application Infrastructure Operating System requires a similar controlling unit that could interface with the infrastructure (container host operating system and/or the management plane for elastic infrastructure could become the equivalent to device drivers in Linux OS), manage processes (containers), allocate resources (managing the node/container resources) and handle security. Under such a model, Kubernetes could be the kernel as it is capable of handling infrastructure resources, manage containers and allocate resources efficiently and could handle security in the future.
Or in Riek's words: "It has become clear that the future of the enterprise operating system is a distributed one of clusters running orchestrated containerized services. While docker / OCI define the package format for containerization, Kubernetes provides the 'meta-kernel' to orchestrate the cluster and its applications."
SEE: Why containers are critical to successful DevOps projects (Tech Pro Research)
The stakes, in short, are very, very high.
Code as currency
Small wonder, then, that vendors are racing to contribute to Kubernetes, the default choice for this data center operating system. In open source, code is the currency by which developers (and the companies that employ them) gain influence in a project. Good code tends to yield more influence and responsibility. It's not surprising, therefore, that we've seen everyone from Oracle to AWS piling into Kubernetes, even if not always super willingly.
There has been a tug-of-war over Kubernetes talent, with Microsoft hiring Kubernetes founder Brendan Burns from Google, for example. Despite these movements, Google still contributes most to Kubernetes, with Red Hat coming in second. If you're an enterprise making a big bet on containers, you're likely going to put your trust in one of these top contributors to Kubernetes, (rightly) figuring they'll be the best positioned to support your needs. Sure, it's possible, as Teridion CEO Christopher Keene stated, that there may be "room for a new entrant" in the Kubernetes battle, but safer bets go to those that contribute most.
Like Google, the originator of Kubernetes. In some ways, Kubernetes is a convenient on-ramp to Google's Cloud Platform. No company on earth has more experience running containers at scale, and conveniently Google's experience is with Kubernetes (or its kissing cousin, Borg), making Google Cloud an appealing place to run Kubernetes.
Google's Achilles Heel, however, is enterprise. This is starting to change, but it's unclear whether Google can become dull fast enough. To the extent that enterprises are looking to run more like Google and are prepared to do so, Google is the ideal vendor. But for the majority of enterprises stuck in legacy land, the Google way isn't an aspiration. It's scary.
For example, enterprises expect long-term support on things that were never in perpetual beta. Red Hat supports RHEL for 10 years. Over half of its engineers work on sustaining engineering, updating old code rather than focusing on new feature development. That's the sort of commitment to boredom you must have to compete for enterprise dollars, and it's simply not in the Google DNA. Not surprisingly, then, former VMware executive Mathew Lodge, who knows a thing or two about boring enterprise software, has given the nod to Red Hat as Kubernetes king, arguing they "understand how to sell enterprise licenses."
SEE: Special report: Riding the DevOps revolution (free PDF) (TechRepublic)
There are other players who can't be discounted. Microsoft, for example, is so strong in both on-premises workloads and public cloud that it will always be a contender. AWS, despite dragging its feet on Kubernetes, also stands out, even despite its relatively small contributor base.
For now, however, the two most likely Kubernetes winners are Google and Red Hat, the top two contributors. Each offers a very different value, with Google promising a leap forward in how companies operate their IT and Red Hat holding offering a more comfortable way of getting there. The ability to make complex, cutting-edge code like Kubernetes ready for slow-moving enterprise consumption, however, could be the difference.
- Why Microsoft should acquire Docker to better compete against Kubernetes (TechRepublic)
- Google's real Kubernetes magic is all about community, not code (TechRepublic)
- The cloud war moves to machine learning: Does Google have an edge? (TechRepublic)
- Google finally gives developers access to its cloudy secret sauce (TechRepublic)
- Why Kubernetes may be a bigger threat to Amazon than Google's cloud (TechRepublic)
Matt is currently head of the developer ecosystem at Adobe. The views expressed are his own, not those of his employer.
Matt Asay is a veteran technology columnist who has written for CNET, ReadWrite, and other tech media. Asay has also held a variety of executive roles with leading mobile and big data software companies.