VictorOps is now Splunk On-Call! Learn More.
Most discussions about the merits of Docker Swarm vs. Kubernetes focus on large-scale deployments. But, what if you’re running your containerized app on a single host or a small cluster? In that case, the considerations for choosing Swarm or a Kubernetes implementation tend to be different.
With that reality in mind, here’s a look at the benefits and drawbacks of Docker Swarm vs. Kubernetes for single-host environments. We’ll consider not just vanilla Kubernetes but also lightweight Kubernetes variants like k3s, Minikube, and MicroK8s. We’ll also touch on where Docker Compose fits within all of this too.
I don’t think it’s going too far to say that, at this point, many folks have almost written off Docker Swarm as a production-grade container orchestration tool. Kubernetes ate Docker’s lunch a year or two ago and Kubernetes has become the go-to orchestration solution for most large-scale container deployments.
But, that doesn’t mean Docker Swarm has nothing to offer. There are several reasons why you might consider using Swarm, especially for small-scale deployments:
At the end of the day, Swarm is less complicated to configure and manage than Kubernetes. This might be a downside in a highly complex, large-scale deployment where you need all of Kubernetes’s features. But, for a simpler, single-host environment, there’s an argument to be made that Swarm has just the right amount of functionality to do what you need without making things too complicated for you.
On most Linux distributions, installing Swarm is as simple as installing the Docker Engine package. This means that, on a single host, you can install Swarm in just a few commands and be up and running in minutes. Kubernetes is more complicated to install, even if you use one of its lightweight variants.
When you use Swarm, you can work from the Docker CLI that you probably already know how to use (assuming you have worked with containers previously). If you use any form of Kubernetes, you need to master additional Kubernetes CLI tools.
Although mainstream Kubernetes is a well-supported tool, the same cannot always be said of its lightweight variants. Thus, if you want a lightweight orchestrator that’s also well-documented and well-integrated with other tools, Swarm is a better choice overall.
On the other hand, a few cons of Swarm can make a case against choosing Swarm over one of the lightweight Kubernetes implementations. The biggest drawback of Swarm is that, following the Mirantis acquisition of Docker Enterprise in November 2019, the future of Swarm remains somewhat uncertain.
To be clear, this doesn’t mean Swarm has no future, despite rumors that you may have heard to the contrary. At the time of the writing of this article, no one has officially announced the discontinuation of Swarm, and there is good reason to believe that if Mirantis isn’t interested in helping to maintain it, the community would.
Still, if you had to place money on whether Swarm or Kubernetes (and its lightweight variants) are going to be around in five, ten, or twenty years, the smarter bet would be on Kubernetes. So, although this consideration has nothing to do with Swarm’s actual functionality, it may be a reason to opt-out of relying on Swarm for production deployments.
You could also make a case that Kubernetes skills are in greater demand than expertise in Docker Swarm (and that was the case even before Mirantis’s acquisition of Docker Enterprise). For that reason, you might choose to avoid Docker Swarm and use a lightweight Kubernetes distribution instead, because teaching yourself Kubernetes may prove more valuable than honing your Swarm skills.
With that being said (and putting aside any worries about the future of Swarm), I tend to think that Swarm is a better fit for single-host environments, even though I prefer Kubernetes for larger-scale deployments. But, it’s a close call; depending on your preferences and priorities (not to mention where Swarm stands development-wise in a year or two from now), a lightweight Kubernetes implementation might be a better fit.
If you’ve read this far, you might be wondering, “Why not just use Docker Compose to manage your single-host environment?”
That’s a fair question. Compose has some obvious selling-points (some of which overlap with those of Swarm and some of which double-down on Swarm’s benefits):
So, for single-host environments, Compose can be a good fit. On the other hand, it’s so simple that it may not provide all of the automation you need. Compose doesn’t smoothly support rolling updates (technically it can do them, but it’s tricky). Container restarts are also iffy with Compose.
Basically, Compose provides very little automation. This is fine if your environment is so small that you can manage things manually – which may be the case if the purpose of your single-host deployment is simply to run dev testing, for example. But, if you’re dealing with more than a handful of containers, Compose may not cut it.
Choosing between Swarm and Kubernetes (and Compose) for single-host environments is tough. Each of these tools are capable of getting the job done. However, Swarm and Compose have the advantage of being simpler to set up and use in many respects, whereas Kubernetes and its variants tend to offer more features – not to mention a greater assurance they’ll remain actively developed for years to come.
Whether you’re building on Swarm or Kubernetes, you need a way to notify engineers of major issues in real-time with actionable context. Sign up for a 14-day free trial of VictorOps today to start doing this yourself.
Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure and networking. He is Senior Editor of content and a DevOps Analyst at Fixate IO. His latest book, For Fun and Profit: A History of the Free and Open Source Software Revolution, was published in 2017.