Why Did Kubernetes Win?

Kubernetes won the Container Orchestration War on 29 November 2017. On that day AWS announced their Elastic Container Service for Kubernetes (EKS).

Preceding Amazon’s announcement were the announcements from Mesosphere, Pivotal, and Docker of native support for Kubernetes. Those are the providers of most of the key offerings in the container orchestration space. That's on top of Google and Azure offering managed Kubernetes services and OpenShift being based upon Kubernetes.

Why did all of these providers choose to support Kubernetes? Why, for example, is Amazon offering EKS?

For Amazon it's because customers want it and so many AWS customers are already running Kubernetes on AWS, with many managing their clusters themselves. Given that Google and Azure offer easier managed Kubernetes services, it makes sense for AWS to make the AWS Kubernetes experience easier.

But why have users chosen to run Kubernetes on AWS when other providers were already offering managed services? Many may prefer AWS as a cloud provider but was that the only reason? If so, why have so many chosen Kubernetes over AWS ECS?

The Secret to the Success of Kubernetes?

Organizations have so far very clearly preferred to run Kubernetes on AWS instead of other clouds, according to the Cloud Native Computing Foundation’s March 2017 survey results:

Notice that Datacenter also ranks high. We can start to understand this pattern by looking at survey results published by CoreOS on drivers for container orchestration. Application portability and hybrid and multi-cloud solutions feature very prominently:

Cluster federation is a big factor in the success of Kubernetes as this can be used to support multi-cloud or hybrid cloud use-cases, giving it a big advantage over AWS ECS. But this alone doesn't explain why Kubernetes has become so popular relative to other tools.

We can understand this better by looking across a range of factors — we'll look at how organizations wanted the flexibility of Kubernetes for hybrid cloud, multi-cloud and its general extensibility. What will emerge is a theme of decision-makers trying to retain flexibility and leverage their existing infrastructure.

Hybrid Cloud

We've seen already that organizations have been keen on hybrid cloud. This is even clearer in RightScale's 2018 survey, which found up to 51% of large companies using hybrid cloud.

The reasons for hybrid cloud are concerns like leveraging existing hardware, and needing to meet regulatory or security restrictions requiring data to be kept on-premise. It can also be about resilience and being able to maintain some level of service in the case of failures.

Multi-Cloud

According to RightScale's survey, up to 81% of large companies are choosing a multi-cloud strategy. CoreOS suggest that a big part of the reason is wariness about commercial lock-in and a survey by Stratoscale indicates that up to 80% of organizations consider cloud lock-in a major concern.

If your software needs rewriting in order to move it to another cloud provider, then your cost of going elsewhere is high. So if the price goes up then you either take that pain or swallow the price increase. Organizations may be attracted to multi-cloud in order to mitigate this risk.

If you're committed to a multi-cloud strategy then having the option to run the same orchestration technology on different clouds can be appealing even if you don't typically use multiple clouds in a single project. It can allow you to choose your orchestration technology for a particular project before choosing the Cloud provider and to ensure that orchestration skills can be re-used across projects.

It seems the market wanted to be able to choose orchestrator independently of their cloud providers and to be able to use multiple providers. Given the popularity of AWS, it makes sense that many would want to be able to choose Kubernetes as the orchestrator and use AWS prominently in their setup. Given that Kubernetes was not being offered by AWS and was being offered as a managed service by other providers, using AWS prominently had the added benefit of proving that your choice of orchestrator really was independent of your choice of cloud provider/s.

It is possible that AWS is not only figuring heavily for worker nodes and is also being used for master nodes in self-managed setups. Despite the availability of managed Kubernetes services, a 2018 analysis by TNS revealed 91% of Kubernetes deployments being handled internally. This path has challenges but provides assurance that you can adequately customize your setup and add to it later as you need to. Once enough people take this path and share their knowledge they can help to make it easier for more to join them and this can create a snowball effect.

Open and Extensible

With the market committed to avoiding cloud lock-in, Kubernetes had a big advantage over AWS Elastic Container Service. But what about the other players in the market — how did Kubernetes pull ahead of them? Here the open and extensible ethos of Kubernetes is important.

The success of Kubernetes relative to the Mesosphere DC/OS, Docker Swarm, or Pivotal Cloud Foundry centers on users not wanting to be locked into tools or languages as a result of their choice of orchestration product. Some of this may have been about the line between the enterprise and open-source offerings and a perceived lock-in with the orchestration tools themselves. But more important was the range of options that the orchestration layer could keep open. The orchestrator's support for a wide range of infrastructure, tooling and language stacks (especially the organization's existing tooling) figure heavily in TNS's 2016 survey results as stated evaluation criteria for container orchestrators.

Kubernetes was designed to be extended and people really are extending it (e.g. OpenShift) and contributing to the open source project. The key orchestration concepts are carefully abstracted to not be language-specific or tool-specific. There are no restrictions on supported languages. Docker is widely used for the container runtime but even this is optional. This approach, together with the CNCF's welcoming of a wide range of corporate partnerships, has encouraged confidence in Kubernetes as a community project (as opposed to associating the project to a particular vendor/s). GitHub's 2017 Octoverse report reveals a vibrant open source culture around Kubernetes:

A vibrant open source culture, together with a pluggable design, means a wide range of options, plug-ins, and tools.

The success of Kubernetes looks like a success for both open source and for consumers having a choice of cloud provider. It also reflects organizations wanting to transition to cloud but doing so cautiously, making use of their existing tools and infrastructure as part of the journey.

Has Kubernetes Really Won?

There is no clear definition of "won." But Kubernetes looks set to become a standard — not in a formal sense but more in a de facto sense of a common ground emerging. The industry has found itself in need of a standard for orchestration to parallel the way that Docker has become a standard for containers. Kubernetes appears to be it.