Is Kubernetes Now Bigger Than Docker?
Docker made containers famous. That can be easy to forget, however, because Kubernetes has now become the talk of the town—which is a big change from a few years ago, when Docker dominated the conversation.
Docker certainly didn’t invent container technology. But when Docker launched in 2013, its tool chain and marketing made containers widely popular for the first time.
It helped that Docker came along at a time when DevOps was gaining steam and organizations were looking for a technology that could deliver consistency between development and deployment environments—which is exactly what containers do.
Thus, Docker established a pretty big name for itself early on.
The Shift from Docker
If you look around the container ecosystem today, however, Kubernetes seems to have become a much hotter topic than Docker. It’s not just that interest in Kubernetes has now solidly surpassed interest in Docker Swarm, as I’ve noted previously.
It’s that in some cases, Docker itself is left out of the conversation entirely.
Projects now describe themselves as being “Kubernetes-native,” without mentioning Docker. People also now debit the merits of “Docker vs. Kubernetes.”
They Are Not Opposites
These trends are interesting because they are not competing technologies, of course.
Docker provides the core container technology. Kubernetes is a tool that can help you deploy Docker containers. It’s only one of several such tools. You don’t have to use it to use Docker—but you can’t use Kubernetes without also using software from Docker.
Discussing “Docker vs. Kubernetes” is, therefore, like debating “corn vs. turkey.” They are different things that serve different purposes. There are no situations where you’d choose between the two, just as I can’t think of any where you’d choose between an ear of corn and a turkey to achieve the same goal—although you might have corn alongside your turkey. (Forgive that metaphor. I’m already in a Thanksgiving mood.)
As for the idea of being “Kubernetes-native,” that implies that you’re Docker-native, too. Except in a few unusual cases, Docker provides the underlying technology that powers the clusters that Kubernetes manages.
It’s possible, of course, that when many people talk about it as if it were an alternative to Docker, what they’re really doing is using “Docker” as shorthand for “Docker Swarm.” Swarm is a direct alternative. This type of usage makes more sense.
Still, it’s clear that in many cases, people are talking as if Kubernetes itself were the only thing you need to run containers. That’s bad for Docker both because it undercuts interest in Swarm (which is an important part of Docker’s commercial strategy) and, most dangerously, because it makes the entire Docker software stack seem like a bland, boring technology that only becomes usable when you add Kubernetes to it.
Is Docker Going the Way of GNU?
Using the word “Kubernetes” to refer to a larger stack of software that also includes Docker is like using the term “Linux” to refer to operating systems that are built using the Linux kernel in conjunction with utilities from the GNU project.
GNU fans would prefer that you say “GNU/Linux,” because Linux is just a kernel. If you had just Linux, you couldn’t build a working operating system. You need GNU software to accompany it.
Still, most people today say just “Linux” to refer to such operating systems. GNU has been written more or less out of the picture.
I sense that something similar may be happening to Docker. Kubernetes has gained so much momentum that it is becoming synonymous in some circles with a Docker-based container environment, although in reality it is only one part of such an environment.
Should we start pushing “Docker/Kubernetes” as a fairer alternative term? Or “Dubernetes”? Maybe “Dockernetes”? I don’t know. But I do think the tendency to forget to mention Docker says something important about just how much of an overriding force Kubernetes has become within the container world.
