Swarm 2030. Let's Go!

Hey, it's Brett and this is DevOps and Docker talk. in this episode, I have a quick update on Swarm and it's good news this time from my weekly live stream on Thursdays. So. I hope you enjoy.

I'm gonna talk about Swarm for a minute 'cause I've got some good news. You Swarm people. You've been waiting for some good news and now we have it. a couple months ago, early 2025, there was a release note that came out from Mirantis.

Oh, and you don't know about Mirantis. let's catch you up 30 seconds. Put it on the clock. Docker back in 2019, sold all their enterprise assets, majority of the staff all were sold to Mirantis.

Docker decided to go back to its roots and build developer tooling only, and not focus on orchestration and production servers. Swarm wasn't sold because it's open source, so the copyrights are still owned by Docker. Mirantis only took the closed source bits, Fast forward six years later, Mirantis is still supporting Swarm. They have enterprise customers.

People are paying for support of Swarm, they've added features, they've added new storage support, kinda like with Kubernetes CSI and that's kind of rolling along. It's not as awesome and as big. It's a 1.0 release.

there have been things that have happened to swarm. So people have been looking for the big sign of, can I rely on swarm? And earlier this year there was a sign that was the opposite of that. Portainer pointed out that they found in the recent morant release notes, particular words that implied or if you tried to read the tea leaves, they kind of suggested people.

Would no longer be getting swarm updates in the paid enterprise portal orchestrator thing, and that it was only gonna be Kubernetes going forward. so Portainer, another company that can manage Kubernetes and Swarm was calling attention to these release notes and asking questions that no one had answers to. I did a video on that. it was called Is Swarm, end of Life.

I read through this, tried to interpret it. I reached out to Mirantis talked to Docker maintainers, Mirantis maintainers, swarm maintainers, people in charge of Mirantis, people in charge of product, and tried to figure out what was going on and everything. I heard everything from internal to Docker to internal. Was the message that Swarm is fine.

Swarm works. We will, we're still supporting it. It ships with every version of Docker. with every version of Mirantis runtime, and we still all like it.

We're not expanding it's functionality at a rapid pace. It's not a majority of revenue of the businesses anymore, so it's not dead, but nobody believed that it was gonna be pulled, pulled out. In fact, I think some of paraphrasing quotes were things like a maintainer saying, there's really no reason for us to pull out swarm out of Docker engine. It would be a lot of work to do that.

Then we would have to declare to everyone that this is no longer there. It would be a whole bunch of work for not really any benefit because they still patch all the code. They still have to maintain any cvs that show up. swarm kit, the library, and then there's networking libraries and the things that come into Docker engine to maintain swarm and then some of the great swarm community we have in Discord.

We're pointing out that there's been some challenges lately with DNS and networking and it looks like that's getting. Uh, fixed. And then yesterday I noticed a brand new post, which is even more good news. So over at Mirantis about every year they post they're going to keep maintaining swarm.

Basically a commitment to say, Hey Swarm fans, we hear you we're still taking support money from you. We're, in fact, I've heard from people that pay Mirantis for support and they're, they're both fine with Swarm. Happy to use Swarm in certain occasions. They might also have Kubernetes and other occasions still using Swarm.

They're happy to pay Mirantis support for it to have enterprise support. they get on the phone with Mirantis. They talk about good that they have good support, they feel confident in it, but they also are reading tea leaves and want to be certain that the future of Swarm, at least as far out as we can all see, is going to be maintained or supportable. And, nobody is expecting promises of future features.

People just wanna make sure this thing is gonna still work in two years. So we created a GitHub repo awesome list a few years back. I keep track of all the news. the last time we've heard anything from Mirantis is I think in 2024.

So it's been six months and Mirantis tends to go six months or a year in the last five years before announcing, Hey, just a reminder, we're still maintaining swarm. We still think it's great. So they've got another post as of yesterday, and this is a pretty good one because they're announcing five more years of support for swarm. So I think when they first did this in I'm trying to remember, For the next three years, for at least the next three years.

This was in 2022, so that would be three more years. That's now April, 2025 but they posted on July 1st. Swarm container orchestration is simple, powerful, and compatible with tooling and workload. Developers know in their bones.

Mirantis will support Swarm on its Mirantis Kubernetes Engine dual Orchestrator Kubernetes plus Swarm platform through 2030. So we now have five and a half years of promised support for Enterprise Swarm, which implies that the open source swarm that most of us use in Docker So the Docker engine is open source and it's all upstream. Docker engine's upstream from Mirantis. Mirantis is probably, upstream from the Mirantis Kubernetes engine.

this particular product, this one where it's the combo of Kubernetes and Swarm, that's the same core product that I understand that came out of Docker data center and Docker Enterprise. They renamed it a couple times. That goes all the way back to like 20 15, 20 16. And I was one of the early beta deployers of Docker data center let's keep going.

Swarm continues to offer a powerful value proposition for organizations That need simplicity, speed, and operational efficiency. In container orchestration. It enables teams to move fast, deploy with confidence and maintain uptime without the complexity of managing Kubernetes control planes or custom resource definitions. That's why we're making a long-term commitment to Mirantis Kubernetes engine version three.

That was the version that was in question at the beginning of the year. So it, so me and others provided feedback to Mirantis saying, Hey, your naming is kind of confusing 'cause you've released this new version four of MKE and you're saying version three, which we all would assume is now deprecated or archived. but that turned out to not really be the case. It was sort of a naming challenge for them.

And version three is going to be maintained. So version three is our flagship container orchestration platform. Swarm will be fully supported through at least 2030. And Mirantis will continue to provide first class support for both Kubernetes and Docker Swarm.

Why Swarm still matters. MKE three is the most scalable, reliable, and secure platform on the market for orchestrate container workloads on both Kubernetes and Swarm in a single solution. It's trusted by hundreds of customers worldwide to power their mission critical infrastructure from cloud native microservices to distributed edge deployments. when Docker sold to Mirantis, there was a belief that it was around 700 customers of Swarm or of Docker data center that they were moving over to Mirantis.

I'm just noticing they didn't say thousands. Doesn't sound like they've 10 x the business yet. We continue to see widespread adoption of swarm across verticals like manufacturing, financial services, energy and defense, especially in environments where operational predictability and low overhead are non-negotiable, meaning developers using Docker also prefer Swarm to enable a simple, seamless workflow from desktop to production. For these use cases, swarm remains a vital tool in container orchestration Additionally, MKE three features both FIPs one 40 dash two validated encryption and the DSA Stig compliance.

And we continue to get new inquiries from US federal agencies as well as organizations and other highly regulated industries. This is actually true. Going all the way back to 2019, 2017, I would go to Docker's Federal Summit, in Washington DC or the DC metro area. we'd get a lot of federal agencies from the US interested in Docker.

This was early days, right? 2017. These, this was back when Kubernetes and production was still. You were, you were still very leading edge the agencies were trying to figure out how to use orchestration because they were really liking Docker, but they needed something to handle many servers.

And so their problem was, is at the time, Kubernetes wasn't yet approved for most government agencies. the Kubernetes ecosystem hadn't matured to the point that there was all these different official vendors with stable products that they felt reli, but they had approved for, for Docker engine. And so the Docker engine was inside of these servers, already in these government agencies. And so those of us that were like of several of us that were captains who were fans of Swarm, would go around in the conference and say, Hey, um, I know you, you don't get to have Kubernetes yet, but, but you actually already have an orchestrator.

It's actually built into Docker engine. All you gotta do is Docker swarm, a knit, and boom, you can do. 70% of what Kubernetes could do at the time it was early days, but we were excited to like sneak it in through the back door because they just really wanted to solve problems with containers and they were just feeling limited by their purchase decisions and their approval decisions and they had Docker. So Mirantis in this 2025 document is confirming that that's still the case.

there are still occasions where adding all these different products to Kubernetes isn't necessary when you're maybe using it on manufacturing equipment and you maybe do something very simple. I've heard that from Port Taner who has enterprise customers, machine, transportation customers, stuff like that. And they're confirming that there are use cases where Kubernetes is still too heavyweight, still too many hardware requirements and complexity requirements. And they just need, essentially, like what Swarm is a single binary that runs the container, engine, runs the orchestration engine, runs the secret storage database, maintains all the networking connections and the DNS all in a single binary.

now this is interesting 'cause this is looking ahead and I wanted to know some of my biggest issues with swarm and beefs with swarm, haven't necessarily been addressed. I'm always hoping that Mirantis will address them. One of them is the YAML bifurcation of the YAML speck between compose and swarm. And they're getting farther apart.

And it's unfortunate because originally the whole idea was that the YAML spec used for compose will also be usable in swarm. And that's no longer the case. which is fine from, an enterprise deployment perspective because we weren't really using compose files locally and then just throwing those into a cluster and production, they were usually different files, but at least the spec and the functionality was very similar. So we didn't have to learn two standards.

I guess that's the problem. And then my other beef with that is that standard hasn't really moved forward. So we still don't have a swarm API to talk directly to a stack. Which is essentially what Kubernetes YAML is.

It's a stack of different resources that you can shove into one thing and deploy all at the same time. Well, we don't technically have that on the swarm API yet. I keep asking for it. I keep hoping, but, um, you know, it's open source, so PRs are welcome.

So, stateful workflows with CSI support to extend swarms utility, we've invested in support for the container storage interface, or CSI with MKE three. This enables swarm users to run stateful workflows like databases, data pipelines, and AI inference servers with persistent storage backends by enterprise grade systems with CSI support. You don't need to switch to Kubernetes just to gain storage orchestration. Swarm users can now run modern data heavy applications with the same simplicity and resilience they've always counted on.

I wanna pause on CSI for a second because it turns out that this maybe is a little bit more hand wavy marketing For this new CSI functionality and swarm to be taken advantage of CSI, providers or storage providers have to update their drivers, to work with Docker Engine and Swarm. And as far as I know, most of them have not done that, but we are trying, we meeting the community. So if you know of anything, please throw in an issue or a PR the whole goal, by the way, of this awesome swarm list on GitHub is to track what currently works and is still supported because there's a decade of swarm stuff out there.

We even had a version of swarm before swarm called Swarm Classic, and that's not really the same thing. It was a bolt-on, add-on to Docker engine. It's not been supported in a long time, but it's not compatible with, with what we called swarm mode or now just swarm and all of these things, you know, have cycles and, and companies came in and built stuff for swarm. And then when Kubernetes won in the popularity contest, they removed their swarm support.

So things broke over time that we thought were working. I've tried to maintain this, This warm, awesome list. And not just news, but also official sources of documentation, places to go for questions and answers and chat. my Discord server, and places where you can find tooling that still works for cluster management.

We've got extra on top functionality, gooeys and the like. And then we come to the CSI support. the community's really helped here in finding all the different things that you would maybe want to use for storage and finding out if they have updated their tool for Swarm. most vendors are not paying attention to Swarm anymore.

we've gotta tell them we would love to use their storage, but they've gotta support Swarm and Docker engine. that's slowly happening over the last few years as CSI was officially added. It was added in 2023. So it's been a couple of years and there's been some progress, but I wouldn't say you can assume that everything just works.

I'm very curious to see how people are doing this in production and how they're trying to use CSI in production with Swarm. I've only had a few people come back to me and give me, stories around what works and what doesn't for them or what they're using. To be fair, for years now, ever since like 2019, 2018, I've generally been telling people if you need to support volumes in swarm, that move across node, that's when you need to go to Kubernetes. because that was a rough area.

And to watch people struggle through it, trying to get swarm to work with moving database files from one node to another, it just, didn't work well. There was old open source plugins like, Rex Ray that were slowly degraded over time because they were archived and not maintained. so I've generally just did not felt comfortable advising people that they should go to production with Swarm if they need volume support that is cross node. in those cases, usually what I tell people is if you have to run databases or anything with volume storage, then you're just gonna have to pin that storage to a particular node.

And you just have to know that when that node goes down, you lose the storage. Which means if you're running databases, you need to run the traditional database mirror and just treat that like an old school database mirror where they are pinned to nodes. The rest of your apps can all run and move around as nodes fail, but, these two database nodes are very special. my general recommendation is if you're in the cloud, just use the cloud databases and then use swarm for all of your, all of your non persistent data needs.

And here we are, right? The last little bit I'm going to read is the fun looking ahead. looking ahead, we're not just maintaining MKE three, we're investing in it with a roadmap that stretches through 2030. I'd love to see that roadmap.

Can we have that roadmap? If it's open source, we can at least have the open source roadmap. I think that would give people a lot of confidence that not just, oh yeah, it'll be maintained if you pay us. But also, hey, look, there's actually some things in swarm open source that we're working on, like fixing the networking adding API support for stacks or improving the CSI support because originally when it first released two years ago, I was told by maintainers a at least one maintainer, that this is kind of like a beta 1.

0 trial thing. we need to put more into it. So where is that? what's happening with that?

I'd love to see some status on that. with a roadmap that stretches through 2030 Mirantis is giving customers the long-term stability and strategic flexibility they need to build confidently with swarm. We've needed that confidence for a decade. Docker has never had a swarm page on their website.

It's only mentioned in the docs, never on the website. At least Mirantis has a swarm page whether you're deploying at the edge in the data center or across multi-cloud environments, MKE three lets you choose the right orchestrator for the job without compromise. a lot of marketing fluff in there, but essentially the key takeaway is they have committed to five and a half more years of support, and they have stated publicly that they have swarm features coming. We will have to hope that those swarm features are still in the open source, to my knowledge.

Almost always is true. Like I'm actually having a hard time coming up with anything other than compliance, military government compliance stuff that isn't in ducker engine's swarm, open source. Right? So we have to kind of assume, I would assume at this point that if any features or added to swarm, including improvements to CSI, it would still roll upstream to Docker engine, which means all of us swarm open source people are gonna benefit from the people paying mirantis for swarm support, which is one of the best ways we got to maintain open source in the in the world, is people pay for support.

That support money drives innovation in the open source product, which goes back to people using it who then want support. And that way has worked for a long time. Red Hat was built on it. Ubuntu, I mean, all the major distributions, all the major Kubernetes distributions, including Red Hats and ranchers and everyone else, they're all, they're all built on that model of paid support.

primarily open source. So, yay, we can celebrate if you're a swarm user. I now am changing my opinion from four months ago, three months ago, If Swarm works for you, keep doing it. You have my permission.

Not that you needed it, but you now have it. if you don't wanna use swarm. Totally fine. I'm not advocating for swarm everywhere.

I don't run swarm anymore because I'm just one person and I don't wanna maintain servers and patched oss and reboot servers and replace, instances. I just don't. So I use all the cloud stuff, where I can just run a one line command or throw in my container environment variables and have it run containers natively. Google Cloud run, Amazon, let's see, AWS's, 18 ways to run containers.

Like there's all these other ways to run containers that don't require me to Maintain those servers, patch those servers, secure those servers, monitor those servers. There's so many other ways of higher level abstraction that I do that, but it doesn't mean that everyone has to do that. And it doesn't solve on-prem problems or edge cases where you don't have those. if you have very minimal needs and you don't need the complexity of Kubernetes, like Swarm is back.

Swarm is back, baby. It's back. This is the best we've ever had it. We have a swarm page.

We have an actual swarm homepage. Docker never committed to five years of maintaining swarm. Docker never stated publicly that they even care about Swarm other than the original announcement and the paid enterprise products that they had up until 2019. But ever since 2019, I've never heard a Docker employee state anything publicly about Swarm other than the fact that it exists.

they'll confirm that it exists, but we've never gotten certainty. We've never gotten commitment from Docker, and that's all that people were asking for. they were just asking, Hey, if I deploy this open source and yes, it's free, Is there some indication that it will still exist and not be archived as a project in six months? And I think we have it like this is the best scenario and we might be past the peak Kubernetes hype cycle, right?

Some people are in that trough of disillusionment or whatever people have figured out swarm and Kubernetes and they figured out that maybe they don't need it all the time, or maybe they could do both. Maybe swarm is so simple that in some cases I just don't deploy Kubernetes. Maybe I deploy some swarm and there's no shade here. I'm not hating on any product or any open source.

this is all best effort. But Mirantis has given us that level of certainty that we never really had with Docker, and I really appreciate that of them. So what do I know in addition to those facts, I now have multiple people inside of Docker and Mirantis, the companies that work around swarm or related to swarm, and they're all interested in it. They're all curious about the community feedback.

So if you have contracts with any of these companies, let them know that you're interested in Swarm. Even if you're not running it, just tell 'em, Hey, we're always curious whether Swarm has added more functionality to solve problems so that we don't need Kubernetes. Wouldn't it be wild if a decade after Swarm was released and after Kubernetes rose to prominence that we all kind of looked at Kubernetes and went, yeah, that's really cool and it does really cool things, but, now that, you know, maybe there's budget cuts and AI changes, some things maybe I don't need, All this complexity and maybe some of the things I do, I can get away with simpler stuff then we end up having a swarm resurgence.

If you don't know the history of Swarm with me and the relationship I have with it, I have two courses that Teach Swarm on Udemy. So you can, in this video, you can go down this description, there's a link to my courses. You can buy either my Docker Mastery course, which also teaches swarm or the swarm course, which has a full swarm, walkthrough. it's many hours of swarm.

I've been a big fan of it for specific simple use cases. I've run it myself in production on the internet for years. I've helped many companies deploy it over the years. Even the Old Swarm Classic, I helped a couple of companies deploy that before the swarm, the modern swarm came out swarm mode.

So I've always been a fan of it for people that have simple uses I'm excited to see that there's a team willing to go out there on the internet and say, If you pay us, we will still support you. And we are still investing in this open source project. I'm so happy that we have some clarity on this and that there's a company willing to step out there, especially considering all this AI shakeup, So I think a lot of vendors are just scared to commit to anything because who knows where they're gonna be in 12 months, maybe all this stuff is irrelevant and AI DevOps becomes a thing and the AI will just run all the Kubernetes for us.

So we don't need other alternatives because the AI knows Kubernetes so well that it makes all the hard things simpler. I don't know that it's gonna solve the resource problem, but But you know, we can hope. Thanks for listening. And I'll see you in the next episode.