All Articles
Infrastructure8 min read18 April 2016

Why Kubernetes Won the Container Orchestration Wars

In 2016 there were three serious container orchestration systems. By the end of the year, Kubernetes was clearly winning. Here is why it beat Docker Swarm and Apache Mesos.

KubernetesDockerInfrastructureDevOps

The container orchestration wars of 2016 were brief and decisive. Docker had released Swarm, Mesosphere was pushing Apache Mesos and Marathon, and Google had open-sourced Kubernetes the year before. By the end of 2016, the outcome was not certain but the direction was clear. Kubernetes was winning.

The surface reason was ecosystem. Google brought credibility and a large community. The CNCF (Cloud Native Computing Foundation) gave it neutral governance that enterprises trusted. Cloud providers started offering managed Kubernetes services. The ecosystem of tooling, integrations, and knowledge sharing grew faster around Kubernetes than around its competitors.

But ecosystem effects do not appear from nowhere. They follow something that actually works better. Kubernetes had genuinely better ideas.

The declarative model was one of them. You describe what you want: five replicas of this container, exposed on this port, with these resource limits. Kubernetes figures out how to make that happen and keeps it that way. If a node dies, Kubernetes reschedules the containers. If a container crashes, it restarts it. You describe desired state and the system continuously reconciles actual state to match it.

Docker Swarm was simpler to use initially, which made it attractive for teams getting started. But simpler often means less capable. As requirements grew, Swarm's limitations became apparent. Kubernetes had more concepts to learn but those concepts existed because they solved real problems.

Mesos was powerful but came from a different philosophy. It was a general-purpose cluster scheduler, not specifically built for containers. Kubernetes was purpose-built for containerised workloads and that showed in the fit between the tool and the problem.

The Kubernetes API turned out to be a major advantage that was not obvious at first. The API is extensible. You can add custom resource types that Kubernetes treats like first-class objects. This extensibility allowed the ecosystem to build on top of Kubernetes in ways that were not possible with Swarm or Mesos. Operators, service meshes, and GitOps tools all built on this extensibility.

By the end of 2016, Kubernetes had won in the minds of the infrastructure community even if the enterprise adoption would take another two years to fully materialise. The patterns being developed in 2016 around namespaces, RBAC, and networking became the foundation of how containerised applications run in production today.

Found this useful?

Share it with someone who'd enjoy it.