No. Swarm is not dead.
The TL;DR direct quote from Docker blog after the Kubernetes announcement:
"But it’s equally important for us to note that Swarm orchestration is not going away. Swarm forms an integral cluster management component of the Docker EE platform; in addition, Swarm will operate side-by-side with Kubernetes in a Docker EE cluster, allowing customers to select, based on their needs, the most suitable orchestration tool at application deployment time."
The Death of Swarm is Greatly Exaggerated
You may know I'm a big fan of Swarm Mode. It's an amazingly easy container orchestrator built right into the Docker CLI and engine. It's been the default orchestrator in Docker's Enterprise Edition for the last 1.5 years and used by many hundreds of their big customers, and many more in the free Docker CE edition.
Please allow me to be a fan of Swarm and Kubernetes at the same time! 😍 I believe a healthy container ecosystem should have multiple viable options for the layers of our server stack.
There have been people, in their love and excitement for Kubernetes, that have claimed that Swarm is dead, and being "replaced" by Kubernetes in Docker EE. That is incorrect, and while I feel like Docker's messaging has been clear, I'd like to present a list of things that help set the record straight.
A Timeline of Evidence
- October 17, 2017. At DockerCon EU, Docker announced that they will support Kubernetes as an orchestrator option in Docker Enterprise Edition in 2018, and also in Docker for Mac/Windows starting December 2017. I was there and focused on every word of the keynote. Some people misread this announcement as a depreciation of Swarm or some sort of "product switch"... but it was quite clear in the messaging that Kubernetes was additive and would allow greater choice for EE customers, and was not a forced migration of workloads from Swarm to Kubernetes. Notice this graphic from DockerCon Keynote. Pretty clear right?
- That same week, when I and the rest of the Docker Captains got to sit down with some of the lead engineers, product managers and Solomon himself (Docker founder), one thing was made clear. Current Docker EE customers were quite happy with Swarm, and weren't looking for the "exit" to Kubernetes. What was happening, was that customer teams that already had Kubernetes deployed and staff educated on it, wanted to also adopt Docker EE. Docker started working with the Kubernetes maintainers to integrate a pure upstream version of Kubernetes into Docker EE as a new 3rd orchestrator option. This meant that customer teams using Kubernetes didn't have to choose one or the other, they could use both together.
Docker EE would then give you multiple orchestrator choices and obtain that holy grail of a consolidated "single pane of glass" for container management and security that businesses love in their infrastructure. Everyone wins.
- November 16th, 2017. Docker clarified/stated after the Kubernetes integration announcement that Swarm is a key part of their Docker Enterprise Edition. Maybe this was to help thwart the confusion around Swarms future, I don't know. But, they were so committed to that statement, that they wrote a whole article about it. It seems clear in this first announcement, then again in this announcement, then again in a end-of-2017 wrap up.
- CTO of Docker Solomon Hykes restates it in a tweet.
- See how active SwarmKit still is on GitHub (which is just one of the repo's that affects Swarm Mode features). 23 PR's in the last month (March 2018). Here's a list of new features affecting Docker's cluster tech over last 3 years that I've collected as I use them in every. new. version. This isn't everything and is only major one's affecting Docker CE (free version).
- Many documents, DockerCon talks, and GitHub issues after that state that Swarm is used to provision and manage Kubernetes nodes in a secure way. It's part of the core tooling for how Docker EE automates setup and management of nodes. Swarm is easy today to deploy and secure out of the box with regard to node auth and mgmt protocols, so it makes sense that it would be used to help tighten down Kubernetes during node initial creation.
- Until Docker Enterprise Edition 2.0 is released, there is no Kubernetes option for current Docker EE customers, meaning that the existing 450+ customers paying for Docker EE (that are choosing to use orchestration) are using the two existing orchestrators that EE has supported, starting with Swarm "Classic" in 2015 (which it still supports aka "Basic Containers") and Swarm (aka "Swarm Services") in 2016. Those are enterprises that may not have a reason to switch to Kubernetes and will be just fine on 2.0 with Swarm for years to come.
- Docker's EE marketing focuses on choice. Choice of the underlying OS, choice of cloud or hardware, choice of Orchestrator. As of 2.0, it will support 3. In talks with engineering leads, they would prefer to sunset the Swarm Classic option, which again, was meant to be super-seeded in late 2016 with Swarm Mode, but still have customers that use it, so they do what's right for the customers. It still gets commits! There are also still edge cases that Swarm Classic might support which Swarm Mode does not yet.
- In Docker EE 2.0, Swarm Mode is still the default orchestrator in the "choose your orchestrator" drop-down. Kubernetes is a choice you can make when you want to when deploying stacks (multi-container multi-tier solutions). You can have all three orchestrators running in the same Docker EE cluster.
- March 9th, 2018. Docker blogs on new features coming to Swarm in Docker EE 2.0.
But What About the Docker Cloud Shutdown
NOTE: The Docker Cloud shutdown was not related to Swarm Mode. In fact, nearly all Cloud customers that were using it for server/stack management weren't even using Swarm Mode yet, which was a "beta" feature released in 2017 that was never fully launched. To me, that shutdown was about focusing on their EE product and "trimming the fat" of various tools they've tried to market that (I'm guessing) just didn't take off. I have no insider info on this, just "reading the tea leaves" of Docker Clouds overall usage in my community of customers, other Docker Captains, and my students. It's too bad, as it was way easier to use for deploying a Docker CE cluster in AWS then the manual alternative.
Are You Convinced?
In the end, I don't speak for Docker. I don't control Docker... but I do believe they've tried to be clear here. I'm writing this in April 2018, right before Docker Enterprise Edition 2.0 is released with Kubernetes support... so the future is not written in stone.
I want you to choose the best orchestrator for your team. The "best" to you might just be the one you know well, the one you can afford, or the one that government standards required you to use (see Docker's standards and compliance). I do hope you take Docker Swarm for a spin, and let me know on Twitter what you think and what tools you've decided to use.