Kubernetes is now almost synonymous with container orchestration. A 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 ' .' CNCF survey container orchestration wars A standout feature of the Kubernetes project now is the strength of its . But Apache Mesos and Docker Swarm were both open source too. Why did Kubernetes win over them? open source community 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. The End of the Container Orchestration Wars Kubernetes the Container Orchestration War on 29 November 2017. On that day AWS announced their Elastic Container Service for Kubernetes (EKS). won Preceding Amazon’s announcement were the announcements from , , and 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. Mesosphere Pivotal Docker 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 , 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. already running Kubernetes on AWS 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 Kubernetes over AWS ECS? choose The Secret to the Success of Kubernetes? 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 on drivers for container orchestration. Application portability and hybrid and multi-cloud solutions feature very prominently: published in 2017 by CoreOS was therefore a major factor in the 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. Cluster federation success of Kubernetes 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 were keen on hybrid cloud. This is even clearer in , which found up to 51% of large companies using hybrid cloud. RightScale's 2018 survey The reasons for hybrid cloud, , 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. judging from a 2017 flexential survey Multi-Cloud According to RightScale's survey, up to 81% of large companies were choosing a multi-cloud strategy. that a big part of the reason was wariness about commercial lock-in and indicated that up to 80% of organizations considered cloud lock-in a major concern. CoreOS suggested a survey by Stratoscale 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 revealed 91% of Kubernetes deployments being handled internally. This is a path with challenges but provides assurance that you can 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. 2018 analysis by TNS adequately customize your setup 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 as stated evaluation criteria for container orchestrators. TNS's 2016 survey results Kubernetes was designed to be extended and people really were extending it (e.g. OpenShift) and 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 . This approach, together with the CNCF's welcoming of a , encouraged confidence in Kubernetes as a (as opposed to associating the project to a particular vendor/s). GitHub's 2017 Octoverse report reveals a around Kubernetes: contributing to since the early stages wide range of corporate partnerships community project vibrant open source culture A vibrant open source culture, together with a pluggable design, means a wide range of options, plug-ins, and tools. The Success of Kubernetes 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 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. found itself in need of a standard for orchestration This article was . adapted from a piece I first wrote on the success of kubernetes in 2018

Stacks

Amazon

Apache

Google

Open Source Myths and Half-Truths: Part 1

Move Fast and Break Things? The AI Governance Dilemma

2021 - HackerNoon Contributor of the Year - DATA

2021 - HackerNoon Contributor of the Year - SCRUM

Nominated for 2022 - HackerNoon Contributor of the Year - Innovation

Nominated for 2022 - HackerNoon Contributor of the Year - Scrum

Nominated for 2022 - HackerNoon Contributor of the Year - Agile

Nominated for 2022 - HackerNoon Contributor of the Year - Digital Transformation

Nominated for 2022 - HackerNoon Contributor of the Year - Kubernetes

Nominated for 2022 - HackerNoon Contributor of the Year - Machine Learning

Nominated for 2022 - HackerNoon Contributor of the Year - Agile Software Development

Nominated for 2022 - HackerNoon Contributor of the Year - Product Management

Too Long; Didn't Read

How Did Kubernetes Win the 
 Container Orchestration War?

How Did Kubernetes Win the Container Orchestration War?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Agile Is Not Enough: Empowered On Innovation

10 Ways to Future-Proof Your Business With Cloud

10 Upcoming DevOps Conferences for 2018

101 Stories To Learn About Cloud Infrastructure

The Ten Top Cities for Highest Cloud Engineering Salaries

10 Things to Think About When Choosing a Hosting Provider

Agile Is Not Enough: Empowered On Innovation

10 Ways to Future-Proof Your Business With Cloud

10 Upcoming DevOps Conferences for 2018

101 Stories To Learn About Cloud Infrastructure

The Ten Top Cities for Highest Cloud Engineering Salaries

10 Things to Think About When Choosing a Hosting Provider

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps