Docker Swarm, a User-Friendly Alternative to Kubernetes

Interest in Swarm is on the rise. We see it in internal metrics, conversations with teams about Swarm support, and a steady drumbeat of questions about Swarm’s simplicity relative to Kubernetes.

You might expect that Docker Swarm, an open source project created at Docker, would decline proportionally to Kubernetes’ ascent, but that’s not happening. In fact, except for a post-pandemic lull that has affected both technologies — perhaps everyone was just exhausted and recovering! — Swarm has continued its upward journey just as Kubernetes has.

At Mirantis, we have a pretty good feel for why people choose to use Swarm, because we see it every day in production environments.  More than 100 Mirantis customers utilize Swarm for production workloads, including GlaxoSmithKline, MetLife, Royal Bank of Canada, and S&P Global. This translates to more than 10,000 nodes spread across approximately 1,000 clusters, supporting over 100,000 containers orchestrated by Swarm.

JetBrains’ annual software tool survey has found that 10% of the organizations queried manage their containers using Swarm, a number that has held steady for the past several years.

Mirantis Kubernetes Engine, which is Mirantis‘ enterprise distribution of Swarm, enables customers to deploy both Kubernetes and Swarm nodes (or both), so they can choose whatever works best for them. Combine that with our service and support, as well as the fact that ZeroOps works to insulate our customers from having to struggle with infrastructure, and we’ve seen some common threads in what they say.

It boils down to this: as Kubernetes has taken hold of the development landscape, folks at all levels of the software value chain have learned the value not just of containerization, but also of container orchestration. Kubernetes offers an enormous number of options and covers a wide range of use cases — but this comes with a large amount of complexity that may hinder speedy delivery, especially when that complexity is not needed.

Enter Swarm.

Kubernetes vs. Swarm

In many ways, Swarm is similar to Kubernetes, in that they both orchestrate containerized applications. They both enable you to create a cluster of multiple nodes on which containerized applications can run, and they both enable you to declaratively define how you want those applications to work.

There are, however, some differences between the two systems that lead some people to choose Swarm over Kubernetes.

Complexity or Ease of Use

The most obvious difference between Kubernetes and Swarm is that of complexity; while Kubernetes is designed to provide for virtually any eventuality, Swarm is designed to get you up and running as quickly as possible. It’s like the difference between a professional DSLR camera, which can accomplish virtually anything but needs an expert for even passable photos, and the camera on your phone, which can do pretty much anything the average person needs to take great pictures without requiring a course in photography.

Both systems rely on the YAML markup language, but where Kubernetes uses the concept of objects, such as Pods, Services, Deployments, and so on, all created independently and put together to make up the overall application, Swarm defines applications more holistically, defining everything at once in a way that’s much more readable (and understandable) for a human.

Swarm is also simpler in other ways. For example, Swarm makes operational challenges a bit easier, as the same Swarm configurations can run in multiple environments. Networking in Swarm is also simpler, which can be an asset (easier to understand) or a liability (much less powerful and/or flexible) depending on what you’re trying to accomplish.

Security

Application security is another place where Swarm makes things a bit simpler than Kubernetes, though sometimes at the cost of more complex capabilities. For example, Swarm includes TLS networking out of the box, and all access control is handled through that. So it’s easy to use, but you don’t get the full granular control that Kubernetes gives you with RBAC, admission controllers, policies, and so on.

Scaling

When it comes to scaling the infrastructure, Kubernetes and Swarm are comparable — a maximum of 5000 nodes for K8s vs. 4700 for Swarm — but when it comes to scaling applications, Swarm can also make things easier. Swarm doesn’t include autoscaling (Kubernetes does) but it does include load balancing out of the box using DNS (Kubernetes needs an external component such as NGINX Ingress).

Ecosystem

On the other hand, there are many more applications and components that are built for Kubernetes than for Swarm. To go back to the issue of load balancing, for example, service meshes such as Istio are typically built for Kubernetes, and not for Swarm. In addition, Kubernetes can work with any container runtime that complies with the Container Runtime Interface, where Swarm uses only the Docker Engine runtime. That said, a choice of container runtime isn’t something your typical developer is thinking about. Again, simplicity over extra features.

All of that begs the question: why now?

Why Now?

So if Swarm is such a good choice, why are we only seeing this surge now? Given what we’ve seen from our customers, I believe that it comes down to several concurrent factors that make Swarm an ideal choice right now.

Kubernetes — and thus the idea of container orchestration — is no longer novel and has entered the “Trough of Disillusionment” phase of the Gartner Hype Cycle. That means it’s ready to climb up the Slope of Enlightenment to the Plateau of Productivity, which means that most people have now heard of it and know why they need it–and that it’s not necessarily simple to use.

Add to that the fact that at the time of this writing, the world economy is uncertain and companies are unable or unwilling to spend more than necessary on staff — and skilled containerization talent was already scarce. In this environment, there is a place for easy-to-use tools that get the job done with a minimum of ramping up.

All of this makes Swarm appealing both to those who don’t need the extra capabilities of Kubernetes, and to those who don’t need them yet.

Fortunately, using Swarm now (or for certain workloads) doesn’t preclude using Kubernetes, either simultaneously or in the future. “If you’re already in containers,” one of our customers told us, “it’s not that complicated to move from Swarm to Kubernetes.”

In fact, adopting Kubernetes doesn’t have to represent a difficulty spike; Swarm can serve as a stepping stone to tools that make Kubernetes development easier, such as Lagoon, Knative, and so on, or to Kubernetes training, easing your development team into more complex container orchestration.

The Last Word (for Now)

Swarm has defined a place for itself in the cloud native ecosystem as an easy-to-use, secure container orchestrator that can be used as a training ground for those who don’t yet need all of the features of Kubernetes (right now). So why are we seeing a rise in interest in Swarm? Because as cloud native paradigms become normalized, and as financial concerns loom, now is a good time to carefully evaluate all the tools in the toolbox and choose the one that’s right for a given job.

For many of us, that tool is Swarm.