DevOps and Docker Talk: Cloud Native Interviews and Tooling

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.