Kubernetes vs Swarm - These companies use both

Maybe you’re considering a migration to containers. Or perhaps you’re standing up cloud-native infrastructure for a new project. Either way, you may find yourself weighing two container orchestration systems: Kubernetes and Docker Swarm.

If you’ve already done a little research, you’ve probably encountered some overarching themes: Kubernetes is an industry standard, and Swarm is easier to use. Both of those statements are broadly true, but on their own, they won’t get you any closer to an effective decision about a cloud native platform. 

Unfortunately, a lot of the conversation around Kubernetes vs Docker Swarm is like that: overly general, shallow, and theoretical. Often, they omit a third way: using Swarm and Kubernetes together.

In this article, we’ll walk through the use-cases, benefits, and challenges of both Swarm and Kubernetes—not just in theoreticals, but in the real-world experience of organizations operating at global scale. Then we’ll look at how they’ve used the two platforms together to make their lives easier.

In the 2022 StackOverflow Developer Survey, the Docker container engine was ranked as the most-used, most-wanted, and most-loved tool in its category. According to these results, the majority of developers are using containers and loving it—and many of those who aren’t wish they were. 

It’s no surprise that the industry is undergoing a seismic shift toward containerization. Containers can help you accelerate development, giving you “building block” images and isolated, easy-to-deploy environments. 

The efficiency of containers has given rise to container orchestrators: systems like Kubernetes and Docker Swarm designed to coordinate many containerized services across multiple hosts.

“Orchestrator” makes a pretty good metaphor. Swarm and Kubernetes are like the conductors of vast orchestras, with containerized applications and services instead of instruments. 

Orchestrators make sure that containerized workloads communicate with one another correctly and continue running smoothly even if an individual container—or even host—crashes. By delivering applications in the form of containers, these systems can quickly replicate container-based deployments in order to achieve high availability and resiliency. 

Kubernetes is a container orchestrator originally developed by Google, well-suited for very large scale deployments with many different hosts, applications, or services.

Kubernetes is popular among enterprise users for its ability to scale services across a large number of nodes, as well as its highly extensible API. Today, Kubernetes is regarded as an industry standard and a de facto “operating system for the cloud.” 

As an open source project maintained by the Cloud Native Computing Foundation, Kubernetes is available in a variety of distributions and through a range of vendors. Mirantis delivers Kubernetes as a managed service or with enterprise support through Mirantis Kubernetes Engine.

Docker Swarm is a container orchestrator built into Docker Engine, suitable for deploying applications across multiple hosts for production use. It is directly integrated with the Docker CLI, and this is a big part of its appeal: you can use the same Docker API to manage a container from development all the way through to production.

Mirantis acquired Docker Enterprise in 2019. Today, Mirantis delivers enterprise-grade Swarm—either as a managed service or with enterprise support through Mirantis Kubernetes Engine.

(“Wait”, you might say, “Swarm is part of a Kubernetes platform?” We’ll talk about that a little more in a moment.) 

Kubernetes is unquestionably the most widely-used container orchestrator today. That is important—it bears directly on questions like the ecosystem surrounding the platform. But it shouldn’t be the sole basis for a decision; common use-cases may not match yours. 

There are four major variables to consider:

• Scale

• Ease of use

• Security

• Ecosystem

You could say that Swarm is designed from—and tailored to—the perspective of a developer, rather than the bird’s-eye view of an operator. Broadly speaking, Swarm is interested in helping you get a containerized service from dev to prod with minimal fuss. 

Kubernetes, by contrast, takes a global view. There is an API-manageable abstraction for everything. It’s a rich and configurable system that doesn’t mind shifting additional cognitive burden onto developers. 

These two different design philosophies give rise to many of each system’s respective strengths and weaknesses.

Swarm was designed with relatively small clusters in mind. 

Though Swarm can run well over a thousand containers on a node (depending on the actual workloads in question), its overlay networking implementation limits the number of services per overlay network to around 250 with recommended configurations. 

In the world of Docker Engine, an overlay network enables containers within the network—which may be spread across multiple hosts—to communicate with one another while isolating them from other networks. You can run many different overlay networks to get around the limit, and in some cases this will be not only suitable but appropriate; you may wish to create an additional layer of network isolation in certain circumstances. 

Nonetheless, running thousands of services on Swarm undoubtedly poses networking complications.

By contrast, scale is where Kubernetes shines. It is generally recommended that you run a maximum of 10,000 services per cluster. Though limits will depend on the workloads and infrastructure, the Kubernetes docs define specific upper bounds for a given cluster as:

• No more than 110 pods per node

• No more than 5,000 nodes

• No more than 150,000 total pods

• No more than 300,000 total containers

Kubernetes is infamously complex, with a sprawling API full of concepts that are sometimes unique to Kubernetes. All of that complexity is in service of truly impressive scalability and flexibility. But it also makes learning Kubernetes difficult. Kubernetes shifts a lot of cognitive burden onto developers—at least during the onboarding phase—and for many, it can feel like an alien conceptual paradigm.

Swarm, by contrast, feels friendly. For a developer, learning Swarm asks very little beyond the Docker API, and many basic concepts translate cleanly to Kubernetes, with few Swarm-specific concepts to “unlearn.” 

“We started with Swarm to have an easy learning curve,” says system engineer Patrick Monbaron of Vaudoise Insurance. “Swarm provided quick onboarding without all the complexity of Kubernetes. That was important.”

For organizations concerned about developer experience, Swarm can provide simple orchestration straight from the Docker interface that developers love.

Because Kubernetes is much more complex, it has a lot more moving parts to secure and validate. While Kubernetes is used around the world for countless mission-critical applications, Swarm can be particularly attractive in environments like public agencies where strict security compliance is paramount.

As a less complicated system, Swarm can be easier to validate against security guidelines. This can be especially valuable for agencies seeking a secure managed service. 

“This gets us out of the weeds to focus on what our job is supposed to be,” says the assistant program manager of a U.S. Defense Agency’s Cybersecurity Office. He says the approach returns 80% of his team’s time to focus on application development rather than managing infrastructure. “It’s increased security. No change to the applications. And now that 80% can be wholly focused on improving the application, which is what we need.”

Kubernetes is designed for extensibility as much as for scale, and this may be its single most distinguishing feature, as well as the secret of its success. 

The Kubernetes API enables tight integration with cloud vendors’ networking and storage services, as well as infinite extensibility through custom resources and operators. This means there is a vast ecosystem of Kubernetes tools—both inside and outside the CNCF stable of open source projects—providing functionality beyond the Kubernetes core. Prometheus, for example, provides a robust event monitoring and alerting stack, while Lens gives users a platform for simplified, visual cluster management. 

Swarm, by contrast, doesn’t have extensibility written so deeply in its DNA. There are tools out there for use with Swarm (the HTTP reverse proxy Traefik, for example), but Kubernetes built a virtuous cycle of expansion that has given it a much deeper and broader ecosystem. If you need a piece of functionality on top of Kubernetes, there is a good chance that an extension of some form already exists or is under development. The same is not true for Docker Swarm. 

All of these variables should be considered side-by-side, and in light of your use case. 

• For a relatively small-scale on-prem cluster with strict security requirements, Swarm may be the best option. 

• For a cluster running thousands of services on a public cloud and especially if requiring extension, Kubernetes is a better fit.

In a world of enterprise scale and complex migrations, however, the choice often isn’t either-or, but both-and.

For all their differences, Kubernetes and Swarm share some fundamental similarities. Generally speaking, the same container images run on each. The two systems are both built to support declarative, stateless, services-based deployments, and to maintain consensus across multiple nodes.

In short, the basic patterns are the same. And Swarm can provide a gentler learning curve for teams adopting those patterns. For teams coming fresh to cloud native development, all of this can make Swarm an attractive stepping stone. 

When France’s iconic Société Générale migrated from Swarm to Kubernetes, they found it much easier than their prior move from a monolith to the cloud. “If you’re already in containers,” says Service Manager Laurent Verbièse, “it’s not that complicated to move from Swarm to Kubernetes. We were still using the same line of products—now we’re using Mirantis Kubernetes Engine, which supports both Kubernetes and Swarm.”

A team leader from one of the world’s largest aerospace companies agrees: “It can be hard to just jump into Kubernetes, so it’s nice to have Swarm to get familiar with basic concepts and get started.”

The simplicity of onboarding with Swarm leads some organizations to use both systems. “Now we have devs skilled with Kubernetes,” says Monbaron of Vaudoise. “We’re happy to build Kubernetes on-premises with MKE…On-premises, we’ll keep using Swarm and Kubernetes side-by-side.” 

With either Swarm or Kubernetes, multi-cluster architectures are typically recommended  for clear scoping and to avoid networking challenges that can emerge in large single clusters. 

In a multi-cluster pattern, dual orchestration gives you the flexibility to use the orchestration technology best suited to a particular cluster’s purpose. For example, if you have one smaller set of workloads subject to tight security and compliance requirements, you might use a Swarm cluster for those while running other workloads on Kubernetes. This isn’t without its trade-offs—you’ll no longer be using a unified API—but that may be worthwhile, especially given the minimal API overhead of Swarm.

Mirantis Kubernetes Engine is unique in enabling you to run Kubernetes and Swarm side-by-side from the same management plane. For users who require only Swarm, it provides a Swarm-only mode, but the benefits of dual-orchestration are powerful, and organizations around the world are taking advantage of them.  

When it comes to the decision between Kubernetes and Swarm, there isn’t a simple answer—it depends on your goals and your context, and those might vary even within the same organization. Whether you’re running your clusters as a managed service (which we recommend) or on your own, dual orchestration can give you the flexibility to use the right tool for different situations…or simply to ease the onboarding process, so your developers can focus on doing what they do best.