Athens vs. Sparta. Linux vs. Windows. Emacs vs. vi. These are some of history’s greatest contests between rival factions.
Here’s another one: Swarm vs. Kubernetes. As Docker container adoption takes off, these two container orchestration tools have emerged as the leading contenders (alongside Marathon, perhaps) for organizations deciding how to manage containerized infrastructure at scale.
Which container orchestrator is better? That’s actually a question I can’t answer, since Swarm and Kubernetes both have advantages and disadvantages. Depending on your particular use cases and preferences, you may find that one or the other of these two orchestrators work best for you. Or you might find that they both work equally well.
What I can do, however, is explain the key similarities and differences between Swarm and Kubernetes, and highlight some general trends that might make one or the other of these tools more attractive for particular situations.
Swarm and Kubernetes: What they have in common
Before delving into what makes Swarm and Kubernetes different from one another, I’ll start in the easier territory of explaining what they have in common. You can’t bash one tool because of a feature that is also present in another.
For starters, let’s state the obvious. Swarm and Kubernetes are both container orchestrators. That means they help you launch and manage clusters of containers. A container orchestrator is essential if you want to run containers at scale, since admins quickly reach the limitations of human abilities if they try to manage many containers manually using the Docker CLI. Swarm and Kubernetes automate most of the tasks involved in running containerized infrastructure, such as spinning up more containers in response to an increase in demand.
Swarm and Kubernetes are also both open source software projects, governed by an Apache License 2.0. So you can’t criticize one or the other for being less than open.
The third major feature that Swarm and Kubernetes have in common is the way they are configured. Both use YAML-formatted files to govern how the tools orchestrate container clusters. While the details of these files vary between the two formats, as I note below, the basics of the configurations themselves will be equally familiar to anyone who has worked with YAML files.
Swarm advantages and disadvantages
Now, let’s talk about what’s different. I’ll start by outlining some of the major advantages and disadvantages of Docker Swarm, generally speaking. (Again, what counts as an advantage for one admin might be a disadvantage for another; I’m thinking only in general terms here.)
Some of the nice things about Swarm include:
- Easy installation and setup. Starting with Docker Engine 1.12, Swarm is now baked into Docker itself. That means that if you use the most recent version of Docker, you already have Swarm set up and available.
- Easy integration with Docker. Similarly, since Swarm was developed as part of Docker itself, it integrates quite seamlessly with the rest of the Docker software stack. It hooks directly into the Docker API and is compatible with all of Docker’s other tools.
But Swarm also has what many admins are likely to consider drawbacks. They include:
- It’s tied to Docker. Again, Swarm was developed by and is now a core part of Docker. That’s good if you already use Docker, keep planning to use Docker and like easy setup. It’s not so good if you prefer a different container stack.
- Not as extensible. Swarm was designed with a somewhat narrower purview in mind than Kubernetes. That makes it easy to use: You basically just define how you want your various services to behave, then get to work. But there’s arguably less fine-tuning available, which you might consider a bad thing.
Those are the general characteristics that set Swarm apart. If you’re looking for a summary of the specific features available in the most recent version of Swarm, this overview will come in handy.
Kubernetes advantages and disadvantages
What about Kubernetes? Here are the nice features and characteristics it offers:
- Broader purview. Kubernetes was originally developed by Google before containers were a major part of enterprise computing. You can use Kubernetes to manage any kind of cluster. That makes it handy if part of your infrastructure is containerized, part of it is composed of traditional clusters, and you don’t want to have multiple orchestration tools running.
- It’s not tied to Docker. A number of commercial vendors contribute heavily to Kubernetes development, but Kubernetes itself is an open source project under the auspices of the Cloud Native Computing Foundation. That means that, unlike Swarm, it’s not closely tied to any single company. So if you’re really into neutrality, you might like Kubernetes better. (In fairness, I should note that Swarm is also an open source tool, and Docker has shown no signs of wanting to lock users in. But the fact remains that Swarm is a Docker project.)
But like Swarm, Kubernetes has its imperfections. They include:
- Setup is arguably more complicated. Because Kubernetes supports a broader set of cluster scenarios and platforms, setup can be tricky. That’s not universally true—on some hosted cloud platforms, like AWS and GCE, Kubernetes is basically already set up for you. But if you want to run it on-premises, things will probably be more complicated.
Conclusion: Swarm and Kubernetes are not that different
As I near the end of this post, one thing’s clear to me: It was harder than I expected to think up significant differences between Swarm and Kubernetes.
If I had been writing this article a year or more ago, before Swarm was baked into Docker and when Kubernetes was still more focused on traditional cluster orchestration, it probably would have been easier to contrast Swarm and Kubernetes. But today, they look increasingly similar.
That means that the best way to decide between the two tools is probably to consider which one you already know better, and/or which one is a better fit for your existing software stack. If you’ve used Swarm or Kubernetes previously and have some familiarity with it, stick with what you know. If you run your infrastructure solely on Docker, use Swarm. If you need a more flexible solution, use Kubernetes. Beyond that, there’s not much that is very different between either container orchestration tool these days.