How Did Kubernetes Win the Container Orchestration War?

Kubernetes is now almost synonymous with container orchestration. A CNCF survey found that it is used in production by 78% of respondents. But it wasn't always like this. There used to be several big players in the field and there was talk in the industry of 'container orchestration wars.'

A standout feature of the Kubernetes project now is the strength of its open source community. But Apache Mesos and Docker Swarm were both open source too. Why did Kubernetes win over them?

If we want to understand why Kubernetes won then we have to step back in time. Looking at the great features of Kubernetes now that the dust has settled won't tell us why so many organisations chose Kubernetes back when the battle was in full swing. We need to look at the history and study the data from the time.

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 were 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, did Amazon offer EKS?

For Amazon it was because customers wanted it and so many AWS customers were already running Kubernetes on AWS, with many managing their clusters themselves. Given that Google and Azure offered easier managed Kubernetes services, it made sense for AWS to make the AWS Kubernetes experience easier.

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

Organizations had 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 ranked high. We can start to understand this pattern by looking at survey results published in 2017 by CoreOS on drivers for container orchestration. Application portability and hybrid and multi-cloud solutions feature very prominently:

Cluster federation was therefore a major factor in the success of Kubernetes as this could 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 became 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.

We've seen already that organizations were 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, judging from a 2017 flexential survey, seem to have been concerns like leveraging existing hardware, and needing to meet regulatory or security restrictions requiring data to be kept on-premise. It was also likely about resilience and being able to maintain some level of service in the case of failures.

According to RightScale's survey, up to 81% of large companies were choosing a multi-cloud strategy. CoreOS suggested that a big part of the reason was wariness about commercial lock-in and a survey by Stratoscale indicated that up to 80% of organizations considered cloud lock-in a major concern.

This lock-in concern makes a lot of sense. 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 have been 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 was not only figuring heavily for worker nodes and was 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 is a path with challenges but provides assurance that you can adequately customize your setup and add to it later as you need to. Once enough people took this path and shared their knowledge, they could help to make it easier for more to join them and this may have helped create a snowball effect.

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 were extending it (e.g. OpenShift) and contributing to the open source project. The key orchestration concepts in Kuberentes are carefully abstracted to not be language-specific or tool-specific. There are no restrictions on supported languages. Docker has been widely used for the container runtime but even this has been optional since the early stages. This approach, together with the CNCF's welcoming of a wide range of corporate partnerships, 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 is 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. The industry found itself in need of a standard for orchestration to parallel the way that Docker became a standard for containers. Kubernetes made itself a trustworthy place that the industry could gravitate towards as a new standard.

This article was adapted from a piece I first wrote on the success of kubernetes in 2018.