Everyone everywhere is excited about Kubernetes. The big question is, Why are people are talking so much more about Kubernetes than other container orchestrators?
Is Kubernetes functionally superior to other container orchestrators? Or does something else give it its edge?
Let’s take a look at that question in some detail.
Is It Functionally Superior to Other Orchestrators?
The question of whether one technology is “better” in a functional sense than another one is highly subjective. You can’t prove definitively that one technology is better for everyone and all use cases.
That said, you could make an argument that Kubernetes has certain stand-out functional strengths. One is its support for a variety of container runtimes. Another, perhaps, is its concept of pods, which make it easy to deploy containerized workloads in a consistent way without having to worry about which specific servers are hosting them.
There might be a few other special Kubernetes features you could point to that are valuable for most people. However, I’m having a hard time thinking of a long list of unique features that clearly make it better than other orchestrators. And indeed, if you look at other articles that try to explain why you should use Kubernetes, you’ll notice that they make generic, high-level statements (such as it “can run any containerized application” or that it supports “deploying and updating software at scale“) that apply to any container orchestrator.
Thus, it’s hard to argue that Kubernetes has become the darling of the container community for functional reasons.
Community Backing and Kubernetes’ Rise
Instead, what has really given Kubernetes an edge over other orchestrators is that, from the time it appeared in 2015 as an open source project, it has been supported by multiple organizations.
This is the key differentiator between it and most other orchestrators. Docker Swarm was developed by, and closely linked to, Docker. Mesos originated as an open source project but has close ties to Mesosphere Inc. ECS, Amazon’s cloud-based scheduler, is a decidely AWS-only tool.
In contrast, Kubernetes has a variety of corporate backers and individual contributors. True, Google has always been at the top of the list, and Kubernetes traces its roots to an internal Google project called Borg. But Google hasn’t totally crowded out other contributors. Plus, Google has less to gain commercially. It can use Kubernetes in its cloud, but so can other cloud vendors, and containers overall are a pretty tiny part of Google’s overall revenue stream. The same can’t be said about Docker or Mesosphere.
For these reasons, it has been easier for the container community as a whole to get behind Kubernetes, which users perceive as a community-developed, open-to-anyone container orchestration solution. Using it doesn’t require tying yourself to any one vendor’s container stack of technology, and people like that feeling of freedom.
This, I think, is what really drives Kubernetes’ popularity. Sure, it does a few things different from other orchestrators. But if it didn’t enjoy the broad community backing and freedom from commercial trappings that it does, I doubt it would stand out within the crowded container orchestration market.
To put it another way: If Docker were the main contributor to Kubernetes, or if Google developed it as a closed source project and didn’t allow it to be used on clouds other than GCP, you wouldn’t be seeing so much excitement. It’s not the technical features that really matter; it’s the community-centric vibe and cultural that have arisen around Kubernetes.