1
00:00:04,401 -->
00:00:07,251
Hey, it's Brett and this
is DevOps and Docker talk.
2
00:00:07,731 -->
00:00:13,161
in this episode, I have a quick update
on Swarm and it's good news this time
3
00:00:13,521 -->
00:00:16,311
from my weekly live stream on Thursdays.
4
00:00:16,401 -->
00:00:16,611
So.
5
00:00:17,161 -->
00:00:17,791
I hope you enjoy.
6
00:00:19,871 -->
00:00:23,441
I'm gonna talk about Swarm for a
minute 'cause I've got some good news.
7
00:00:23,711 -->
00:00:24,761
You Swarm people.
8
00:00:25,061 -->
00:00:28,331
You've been waiting for some
good news and now we have it.
9
00:00:28,851 -->
00:00:32,941
a couple months ago, early
2025, there was a release note
10
00:00:32,941 -->
00:00:34,391
that came out from Mirantis.
11
00:00:34,451 -->
00:00:35,681
Oh, and you don't know about Mirantis.
12
00:00:35,701 -->
00:00:37,501
let's catch you up 30 seconds.
13
00:00:37,741 -->
00:00:38,491
Put it on the clock.
14
00:00:39,296 -->
00:00:42,206
Docker back in 2019, sold
all their enterprise assets,
15
00:00:42,206 -->
00:00:44,986
majority of the staff
all were sold to Mirantis.
16
00:00:45,266 -->
00:00:48,356
Docker decided to go back to
its roots and build developer
17
00:00:48,356 -->
00:00:52,466
tooling only, and not focus on
orchestration and production servers.
18
00:00:52,516 -->
00:00:55,246
Swarm wasn't sold because it's
open source, so the copyrights
19
00:00:55,246 -->
00:00:56,416
are still owned by Docker.
20
00:00:56,546 -->
00:01:00,426
Mirantis only took the closed source
bits, Fast forward six years later,
21
00:01:00,506 -->
00:01:02,466
Mirantis is still supporting Swarm.
22
00:01:02,766 -->
00:01:04,236
They have enterprise customers.
23
00:01:04,776 -->
00:01:07,726
People are paying for support of
Swarm, they've added features,
24
00:01:07,756 -->
00:01:12,436
they've added new storage support,
kinda like with Kubernetes CSI
25
00:01:12,766 -->
00:01:14,926
and that's kind of rolling along.
26
00:01:14,926 -->
00:01:16,906
It's not as awesome and as big.
27
00:01:16,906 -->
00:01:18,106
It's a 1.0 release.
28
00:01:18,426 -->
00:01:19,866
there have been things that
have happened to swarm.
29
00:01:19,866 -->
00:01:23,616
So people have been looking for the
big sign of, can I rely on swarm?
30
00:01:24,246 -->
00:01:28,116
And earlier this year there was a
sign that was the opposite of that.
31
00:01:28,306 -->
00:01:32,986
Portainer pointed out that they found
in the recent morant release notes,
32
00:01:33,426 -->
00:01:37,686
particular words that implied or if
you tried to read the tea leaves,
33
00:01:38,256 -->
00:01:40,976
they kind of suggested people.
34
00:01:41,291 -->
00:01:46,631
Would no longer be getting swarm
updates in the paid enterprise portal
35
00:01:47,231 -->
00:01:50,921
orchestrator thing, and that it was
only gonna be Kubernetes going forward.
36
00:01:51,881 -->
00:01:56,051
so Portainer, another company that
can manage Kubernetes and Swarm
37
00:01:56,101 -->
00:01:59,651
was calling attention to these
release notes and asking questions
38
00:01:59,651 -->
00:02:00,891
that no one had answers to.
39
00:02:01,311 -->
00:02:02,571
I did a video on that.
40
00:02:02,571 -->
00:02:04,521
it was called Is Swarm, end of Life.
41
00:02:05,011 -->
00:02:07,321
I read through this,
tried to interpret it.
42
00:02:07,441 -->
00:02:10,691
I reached out to Mirantis talked
to Docker maintainers, Mirantis
43
00:02:10,721 -->
00:02:14,611
maintainers, swarm maintainers, people
in charge of Mirantis, people in charge
44
00:02:14,611 -->
00:02:20,761
of product, and tried to figure out
what was going on and everything.
45
00:02:20,761 -->
00:02:24,961
I heard everything from
internal to Docker to internal.
46
00:02:26,116 -->
00:02:28,906
Was the message that Swarm is fine.
47
00:02:29,206 -->
00:02:30,136
Swarm works.
48
00:02:30,526 -->
00:02:32,176
We will, we're still supporting it.
49
00:02:32,176 -->
00:02:33,856
It ships with every version of Docker.
50
00:02:34,016 -->
00:02:38,516
with every version of Mirantis
runtime, and we still all like it.
51
00:02:38,566 -->
00:02:42,706
We're not expanding it's
functionality at a rapid pace.
52
00:02:42,706 -->
00:02:48,556
It's not a majority of revenue of
the businesses anymore, so it's not
53
00:02:48,556 -->
00:02:52,036
dead, but nobody believed that it
was gonna be pulled, pulled out.
54
00:02:52,126 -->
00:02:58,396
In fact, I think some of paraphrasing
quotes were things like a maintainer
55
00:02:58,666 -->
00:03:03,271
saying, there's really no reason for us
to pull out swarm out of Docker engine.
56
00:03:03,331 -->
00:03:04,951
It would be a lot of work to do that.
57
00:03:05,776 -->
00:03:09,136
Then we would have to declare to
everyone that this is no longer there.
58
00:03:09,136 -->
00:03:12,706
It would be a whole bunch of work
for not really any benefit because
59
00:03:12,706 -->
00:03:14,356
they still patch all the code.
60
00:03:14,596 -->
00:03:17,176
They still have to maintain
any cvs that show up.
61
00:03:17,549 -->
00:03:21,239
swarm kit, the library, and then
there's networking libraries and the
62
00:03:21,239 -->
00:03:27,619
things that come into Docker engine
to maintain swarm and then some of the
63
00:03:27,619 -->
00:03:30,019
great swarm community we have in Discord.
64
00:03:30,169 -->
00:03:33,649
We're pointing out that there's been some
challenges lately with DNS and networking
65
00:03:33,699 -->
00:03:35,109
and it looks like that's getting.
66
00:03:35,931 -->
00:03:36,546
Uh, fixed.
67
00:03:36,596 -->
00:03:44,126
And then yesterday I noticed a brand
new post, which is even more good news.
68
00:03:44,306 -->
00:03:51,706
So over at Mirantis about every
year they post they're going
69
00:03:51,706 -->
00:03:53,026
to keep maintaining swarm.
70
00:03:53,536 -->
00:03:58,276
Basically a commitment to say, Hey
Swarm fans, we hear you we're still
71
00:03:58,276 -->
00:03:59,806
taking support money from you.
72
00:03:59,986 -->
00:04:02,836
We're, in fact, I've heard from people
that pay Mirantis for support and
73
00:04:02,836 -->
00:04:05,536
they're, they're both fine with Swarm.
74
00:04:05,536 -->
00:04:07,276
Happy to use Swarm in certain occasions.
75
00:04:07,276 -->
00:04:10,636
They might also have Kubernetes and
other occasions still using Swarm.
76
00:04:10,696 -->
00:04:13,756
They're happy to pay Mirantis support
for it to have enterprise support.
77
00:04:14,056 -->
00:04:15,506
they get on the phone with Mirantis.
78
00:04:15,526 -->
00:04:19,456
They talk about good that they have good
support, they feel confident in it, but
79
00:04:19,456 -->
00:04:23,356
they also are reading tea leaves and want
to be certain that the future of Swarm,
80
00:04:23,356 -->
00:04:29,246
at least as far out as we can all see,
is going to be maintained or supportable.
81
00:04:29,846 -->
00:04:33,686
And, nobody is expecting
promises of future features.
82
00:04:33,896 -->
00:04:36,686
People just wanna make sure this thing
is gonna still work in two years.
83
00:04:37,376 -->
00:04:42,656
So we created a GitHub repo
awesome list a few years back.
84
00:04:42,656 -->
00:04:44,006
I keep track of all the news.
85
00:04:44,076 -->
00:04:49,056
the last time we've heard anything
from Mirantis is I think in 2024.
86
00:04:49,056 -->
00:04:54,126
So it's been six months and Mirantis tends
to go six months or a year in the last
87
00:04:54,126 -->
00:04:58,716
five years before announcing, Hey, just a
reminder, we're still maintaining swarm.
88
00:04:58,716 -->
00:04:59,646
We still think it's great.
89
00:05:00,096 -->
00:05:05,136
So they've got another post as of
yesterday, and this is a pretty good
90
00:05:05,136 -->
00:05:09,926
one because they're announcing five
more years of support for swarm.
91
00:05:10,526 -->
00:05:16,406
So I think when they first did this in
I'm trying to remember, For the next three
92
00:05:16,406 -->
00:05:18,566
years, for at least the next three years.
93
00:05:18,566 -->
00:05:21,536
This was in 2022, so that
would be three more years.
94
00:05:21,546 -->
00:05:25,346
That's now April, 2025 but
they posted on July 1st.
95
00:05:26,936 -->
00:05:29,936
Swarm container orchestration is
simple, powerful, and compatible
96
00:05:29,936 -->
00:05:31,016
with tooling and workload.
97
00:05:31,016 -->
00:05:32,216
Developers know in their bones.
98
00:05:32,576 -->
00:05:36,806
Mirantis will support Swarm on
its Mirantis Kubernetes Engine
99
00:05:36,836 -->
00:05:43,466
dual Orchestrator Kubernetes
plus Swarm platform through 2030.
100
00:05:44,066 -->
00:05:51,086
So we now have five and a half years
of promised support for Enterprise
101
00:05:51,086 -->
00:05:56,966
Swarm, which implies that the open
source swarm that most of us use
102
00:05:56,966 -->
00:06:02,036
in Docker So the Docker engine is
open source and it's all upstream.
103
00:06:02,036 -->
00:06:03,746
Docker engine's upstream from Mirantis.
104
00:06:03,746 -->
00:06:07,406
Mirantis is probably, upstream from
the Mirantis Kubernetes engine.
105
00:06:07,456 -->
00:06:11,236
this particular product, this one where
it's the combo of Kubernetes and Swarm,
106
00:06:11,446 -->
00:06:17,176
that's the same core product that I
understand that came out of Docker
107
00:06:17,176 -->
00:06:18,766
data center and Docker Enterprise.
108
00:06:18,766 -->
00:06:19,936
They renamed it a couple times.
109
00:06:20,236 -->
00:06:23,956
That goes all the way
back to like 20 15, 20 16.
110
00:06:23,956 -->
00:06:29,616
And I was one of the early beta deployers
of Docker data center let's keep going.
111
00:06:30,336 -->
00:06:33,176
Swarm continues to offer a
powerful value proposition for
112
00:06:33,176 -->
00:06:37,826
organizations That need simplicity,
speed, and operational efficiency.
113
00:06:37,976 -->
00:06:39,116
In container orchestration.
114
00:06:39,236 -->
00:06:42,926
It enables teams to move fast, deploy with
confidence and maintain uptime without the
115
00:06:42,926 -->
00:06:46,796
complexity of managing Kubernetes control
planes or custom resource definitions.
116
00:06:47,126 -->
00:06:49,476
That's why we're making a
long-term commitment to Mirantis
117
00:06:49,496 -->
00:06:50,996
Kubernetes engine version three.
118
00:06:51,836 -->
00:06:54,686
That was the version that was in
question at the beginning of the year.
119
00:06:54,746 -->
00:07:00,716
So it, so me and others provided feedback
to Mirantis saying, Hey, your naming is
120
00:07:00,716 -->
00:07:06,056
kind of confusing 'cause you've released
this new version four of MKE and you're
121
00:07:06,056 -->
00:07:11,126
saying version three, which we all would
assume is now deprecated or archived.
122
00:07:11,726 -->
00:07:13,706
but that turned out to
not really be the case.
123
00:07:13,706 -->
00:07:16,046
It was sort of a naming
challenge for them.
124
00:07:16,436 -->
00:07:18,986
And version three is
going to be maintained.
125
00:07:19,496 -->
00:07:24,176
So version three is our flagship
container orchestration platform.
126
00:07:24,431 -->
00:07:27,161
Swarm will be fully supported
through at least 2030.
127
00:07:27,161 -->
00:07:29,471
And Mirantis will continue to
provide first class support for
128
00:07:29,471 -->
00:07:31,751
both Kubernetes and Docker Swarm.
129
00:07:32,411 -->
00:07:34,091
Why Swarm still matters.
130
00:07:34,331 -->
00:07:38,261
MKE three is the most scalable, reliable,
and secure platform on the market for
131
00:07:38,261 -->
00:07:42,271
orchestrate container workloads on both
Kubernetes and Swarm in a single solution.
132
00:07:42,271 -->
00:07:45,481
It's trusted by hundreds of
customers worldwide to power their
133
00:07:45,481 -->
00:07:48,091
mission critical infrastructure
from cloud native microservices
134
00:07:48,091 -->
00:07:49,471
to distributed edge deployments.
135
00:07:50,011 -->
00:07:57,301
when Docker sold to Mirantis, there was
a belief that it was around 700 customers
136
00:07:57,301 -->
00:08:01,841
of Swarm or of Docker data center that
they were moving over to Mirantis.
137
00:08:01,911 -->
00:08:03,591
I'm just noticing they
didn't say thousands.
138
00:08:03,861 -->
00:08:05,811
Doesn't sound like they've
10 x the business yet.
139
00:08:06,351 -->
00:08:09,741
We continue to see widespread adoption
of swarm across verticals like
140
00:08:09,741 -->
00:08:13,521
manufacturing, financial services, energy
and defense, especially in environments
141
00:08:13,521 -->
00:08:17,271
where operational predictability and
low overhead are non-negotiable, meaning
142
00:08:17,271 -->
00:08:21,171
developers using Docker also prefer
Swarm to enable a simple, seamless
143
00:08:21,171 -->
00:08:22,731
workflow from desktop to production.
144
00:08:23,121 -->
00:08:26,271
For these use cases, swarm remains a
vital tool in container orchestration
145
00:08:26,526 -->
00:08:30,671
Additionally, MKE three features
both FIPs one 40 dash two validated
146
00:08:30,671 -->
00:08:33,611
encryption and the DSA Stig compliance.
147
00:08:34,001 -->
00:08:37,181
And we continue to get new inquiries
from US federal agencies as
148
00:08:37,181 -->
00:08:40,571
well as organizations and other
highly regulated industries.
149
00:08:41,021 -->
00:08:42,131
This is actually true.
150
00:08:42,161 -->
00:08:47,771
Going all the way back to 2019, 2017,
I would go to Docker's Federal Summit,
151
00:08:47,771 -->
00:08:50,431
in Washington DC or the DC metro area.
152
00:08:50,621 -->
00:08:53,501
we'd get a lot of federal agencies
from the US interested in Docker.
153
00:08:53,501 -->
00:08:54,971
This was early days, right?
154
00:08:54,971 -->
00:08:59,051
2017. These, this was back when
Kubernetes and production was still.
155
00:08:59,471 -->
00:09:02,441
You were, you were still very leading
edge the agencies were trying to figure
156
00:09:02,441 -->
00:09:06,311
out how to use orchestration because
they were really liking Docker, but they
157
00:09:06,311 -->
00:09:08,321
needed something to handle many servers.
158
00:09:08,471 -->
00:09:12,401
And so their problem was, is at the
time, Kubernetes wasn't yet approved
159
00:09:12,401 -->
00:09:13,661
for most government agencies.
160
00:09:13,851 -->
00:09:16,791
the Kubernetes ecosystem hadn't matured
to the point that there was all these
161
00:09:16,791 -->
00:09:21,171
different official vendors with stable
products that they felt reli, but they
162
00:09:21,171 -->
00:09:22,971
had approved for, for Docker engine.
163
00:09:23,211 -->
00:09:26,124
And so the Docker engine was
inside of these servers, already
164
00:09:26,754 -->
00:09:29,124
in these government agencies.
165
00:09:29,124 -->
00:09:32,154
And so those of us that were like
of several of us that were captains
166
00:09:32,304 -->
00:09:35,154
who were fans of Swarm, would go
around in the conference and say,
167
00:09:35,304 -->
00:09:39,354
Hey, um, I know you, you don't get
to have Kubernetes yet, but, but you
168
00:09:39,354 -->
00:09:41,004
actually already have an orchestrator.
169
00:09:41,334 -->
00:09:43,134
It's actually built into Docker engine.
170
00:09:43,614 -->
00:09:47,274
All you gotta do is Docker swarm,
a knit, and boom, you can do.
171
00:09:48,279 -->
00:09:52,889
70% of what Kubernetes could do at the
time it was early days, but we were
172
00:09:52,889 -->
00:09:56,099
excited to like sneak it in through
the back door because they just really
173
00:09:56,099 -->
00:09:59,639
wanted to solve problems with containers
and they were just feeling limited
174
00:09:59,639 -->
00:10:03,269
by their purchase decisions and their
approval decisions and they had Docker.
175
00:10:03,629 -->
00:10:09,599
So Mirantis in this 2025 document is
confirming that that's still the case.
176
00:10:09,599 -->
00:10:15,089
there are still occasions where adding
all these different products to Kubernetes
177
00:10:15,089 -->
00:10:18,759
isn't necessary when you're maybe
using it on manufacturing equipment
178
00:10:18,879 -->
00:10:20,529
and you maybe do something very simple.
179
00:10:20,979 -->
00:10:24,669
I've heard that from Port Taner who
has enterprise customers, machine,
180
00:10:25,039 -->
00:10:26,659
transportation customers, stuff like that.
181
00:10:26,659 -->
00:10:30,229
And they're confirming that there are
use cases where Kubernetes is still too
182
00:10:30,229 -->
00:10:33,829
heavyweight, still too many hardware
requirements and complexity requirements.
183
00:10:33,889 -->
00:10:38,569
And they just need, essentially, like what
Swarm is a single binary that runs the
184
00:10:38,569 -->
00:10:43,909
container, engine, runs the orchestration
engine, runs the secret storage database,
185
00:10:44,239 -->
00:10:47,719
maintains all the networking connections
and the DNS all in a single binary.
186
00:10:48,199 -->
00:10:51,649
now this is interesting 'cause
this is looking ahead and I wanted
187
00:10:52,189 -->
00:10:56,809
to know some of my biggest issues
with swarm and beefs with swarm,
188
00:10:57,929 -->
00:10:59,429
haven't necessarily been addressed.
189
00:11:00,594 -->
00:11:02,364
I'm always hoping that
Mirantis will address them.
190
00:11:02,694 -->
00:11:08,064
One of them is the YAML bifurcation of
the YAML speck between compose and swarm.
191
00:11:08,154 -->
00:11:09,654
And they're getting farther apart.
192
00:11:09,744 -->
00:11:14,664
And it's unfortunate because originally
the whole idea was that the YAML spec used
193
00:11:14,664 -->
00:11:16,614
for compose will also be usable in swarm.
194
00:11:16,734 -->
00:11:17,934
And that's no longer the case.
195
00:11:18,484 -->
00:11:23,497
which is fine from, an enterprise
deployment perspective because we weren't
196
00:11:23,497 -->
00:11:27,697
really using compose files locally and
then just throwing those into a cluster
197
00:11:27,697 -->
00:11:30,997
and production, they were usually
different files, but at least the spec
198
00:11:30,997 -->
00:11:32,617
and the functionality was very similar.
199
00:11:32,617 -->
00:11:34,347
So we didn't have to learn two standards.
200
00:11:34,677 -->
00:11:35,637
I guess that's the problem.
201
00:11:35,637 -->
00:11:38,697
And then my other beef with that is that
standard hasn't really moved forward.
202
00:11:38,697 -->
00:11:44,067
So we still don't have a swarm
API to talk directly to a stack.
203
00:11:44,442 -->
00:11:47,292
Which is essentially
what Kubernetes YAML is.
204
00:11:47,292 -->
00:11:50,472
It's a stack of different resources
that you can shove into one thing
205
00:11:50,622 -->
00:11:51,882
and deploy all at the same time.
206
00:11:51,882 -->
00:11:54,542
Well, we don't technically
have that on the swarm API yet.
207
00:11:54,542 -->
00:11:55,412
I keep asking for it.
208
00:11:55,412 -->
00:12:00,422
I keep hoping, but, um, you know,
it's open source, so PRs are welcome.
209
00:12:01,382 -->
00:12:05,372
So, stateful workflows with CSI support
to extend swarms utility, we've invested
210
00:12:05,372 -->
00:12:09,602
in support for the container storage
interface, or CSI with MKE three.
211
00:12:10,292 -->
00:12:13,352
This enables swarm users to run
stateful workflows like databases, data
212
00:12:13,352 -->
00:12:17,042
pipelines, and AI inference servers
with persistent storage backends by
213
00:12:17,042 -->
00:12:19,292
enterprise grade systems with CSI support.
214
00:12:19,292 -->
00:12:22,412
You don't need to switch to Kubernetes
just to gain storage orchestration.
215
00:12:22,682 -->
00:12:26,822
Swarm users can now run modern data heavy
applications with the same simplicity
216
00:12:27,182 -->
00:12:29,192
and resilience they've always counted on.
217
00:12:30,452 -->
00:12:34,502
I wanna pause on CSI for a second
because it turns out that this maybe is
218
00:12:34,502 -->
00:12:37,142
a little bit more hand wavy marketing
219
00:12:37,472 -->
00:12:42,122
For this new CSI functionality
and swarm to be taken advantage of
220
00:12:43,322 -->
00:12:48,942
CSI, providers or storage providers
have to update their drivers, to
221
00:12:48,942 -->
00:12:50,952
work with Docker Engine and Swarm.
222
00:12:51,282 -->
00:12:55,392
And as far as I know, most of them
have not done that, but we are
223
00:12:55,392 -->
00:12:57,532
trying, we meeting the community.
224
00:12:57,532 -->
00:13:02,877
So if you know of anything, please throw
in an issue or a PR the whole goal, by
225
00:13:02,877 -->
00:13:07,917
the way, of this awesome swarm list on
GitHub is to track what currently works
226
00:13:08,067 -->
00:13:11,997
and is still supported because there's
a decade of swarm stuff out there.
227
00:13:12,207 -->
00:13:15,987
We even had a version of swarm before
swarm called Swarm Classic, and
228
00:13:15,987 -->
00:13:17,397
that's not really the same thing.
229
00:13:17,637 -->
00:13:19,887
It was a bolt-on, add-on to Docker engine.
230
00:13:20,037 -->
00:13:24,297
It's not been supported in a long time,
but it's not compatible with, with
231
00:13:24,297 -->
00:13:30,627
what we called swarm mode or now just
swarm and all of these things, you
232
00:13:30,627 -->
00:13:34,527
know, have cycles and, and companies
came in and built stuff for swarm.
233
00:13:34,527 -->
00:13:38,727
And then when Kubernetes won
in the popularity contest, they
234
00:13:38,727 -->
00:13:40,167
removed their swarm support.
235
00:13:40,167 -->
00:13:42,867
So things broke over time
that we thought were working.
236
00:13:43,237 -->
00:13:46,557
I've tried to maintain this,
This warm, awesome list.
237
00:13:46,887 -->
00:13:51,897
And not just news, but also official
sources of documentation, places to
238
00:13:51,897 -->
00:13:53,757
go for questions and answers and chat.
239
00:13:54,097 -->
00:13:58,747
my Discord server, and places
where you can find tooling that
240
00:13:58,747 -->
00:14:01,267
still works for cluster management.
241
00:14:01,267 -->
00:14:04,417
We've got extra on top
functionality, gooeys and the like.
242
00:14:04,837 -->
00:14:06,757
And then we come to the CSI support.
243
00:14:06,807 -->
00:14:11,397
the community's really helped here
in finding all the different things
244
00:14:11,427 -->
00:14:15,327
that you would maybe want to use
for storage and finding out if they
245
00:14:15,537 -->
00:14:17,607
have updated their tool for Swarm.
246
00:14:17,637 -->
00:14:20,007
most vendors are not paying
attention to Swarm anymore.
247
00:14:20,137 -->
00:14:22,897
we've gotta tell them we would love
to use their storage, but they've
248
00:14:22,897 -->
00:14:24,787
gotta support Swarm and Docker engine.
249
00:14:25,127 -->
00:14:29,627
that's slowly happening over the last
few years as CSI was officially added.
250
00:14:29,677 -->
00:14:30,727
It was added in 2023.
251
00:14:30,727 -->
00:14:34,597
So it's been a couple of years and there's
been some progress, but I wouldn't say
252
00:14:34,647 -->
00:14:36,597
you can assume that everything just works.
253
00:14:37,167 -->
00:14:40,437
I'm very curious to see how people
are doing this in production
254
00:14:40,437 -->
00:14:42,957
and how they're trying to use
CSI in production with Swarm.
255
00:14:43,347 -->
00:14:46,867
I've only had a few people come
back to me and give me, stories
256
00:14:46,867 -->
00:14:49,357
around what works and what doesn't
for them or what they're using.
257
00:14:50,527 -->
00:14:55,897
To be fair, for years now, ever since
like 2019, 2018, I've generally been
258
00:14:55,897 -->
00:15:02,437
telling people if you need to support
volumes in swarm, that move across node,
259
00:15:02,437 -->
00:15:04,807
that's when you need to go to Kubernetes.
260
00:15:04,807 -->
00:15:06,637
because that was a rough area.
261
00:15:07,192 -->
00:15:11,062
And to watch people struggle through
it, trying to get swarm to work with
262
00:15:11,542 -->
00:15:15,632
moving database files from one node
to another, it just, didn't work well.
263
00:15:15,632 -->
00:15:19,862
There was old open source plugins
like, Rex Ray that were slowly
264
00:15:19,862 -->
00:15:23,042
degraded over time because they
were archived and not maintained.
265
00:15:23,092 -->
00:15:26,002
so I've generally just did not felt
comfortable advising people that they
266
00:15:26,002 -->
00:15:31,492
should go to production with Swarm if they
need volume support that is cross node.
267
00:15:32,042 -->
00:15:34,592
in those cases, usually what I tell
people is if you have to run databases
268
00:15:34,592 -->
00:15:37,142
or anything with volume storage,
then you're just gonna have to pin
269
00:15:37,142 -->
00:15:38,762
that storage to a particular node.
270
00:15:38,942 -->
00:15:41,672
And you just have to know that when that
node goes down, you lose the storage.
271
00:15:41,672 -->
00:15:44,702
Which means if you're running databases,
you need to run the traditional
272
00:15:44,702 -->
00:15:49,262
database mirror and just treat that
like an old school database mirror
273
00:15:49,262 -->
00:15:51,932
where they are pinned to nodes.
274
00:15:51,972 -->
00:15:55,692
The rest of your apps can all run and
move around as nodes fail, but, these
275
00:15:55,692 -->
00:15:57,162
two database nodes are very special.
276
00:15:57,472 -->
00:16:00,502
my general recommendation is if you're in
the cloud, just use the cloud databases
277
00:16:00,502 -->
00:16:06,082
and then use swarm for all of your,
all of your non persistent data needs.
278
00:16:07,912 -->
00:16:09,052
And here we are, right?
279
00:16:10,432 -->
00:16:14,632
The last little bit I'm going to
read is the fun looking ahead.
280
00:16:14,632 -->
00:16:18,472
looking ahead, we're not just maintaining
MKE three, we're investing in it with
281
00:16:18,472 -->
00:16:20,362
a roadmap that stretches through 2030.
282
00:16:21,442 -->
00:16:22,702
I'd love to see that roadmap.
283
00:16:23,467 -->
00:16:24,547
Can we have that roadmap?
284
00:16:24,667 -->
00:16:28,087
If it's open source, we can at
least have the open source roadmap.
285
00:16:28,567 -->
00:16:31,957
I think that would give people a lot
of confidence that not just, oh yeah,
286
00:16:31,957 -->
00:16:33,667
it'll be maintained if you pay us.
287
00:16:33,667 -->
00:16:37,927
But also, hey, look, there's actually
some things in swarm open source that
288
00:16:37,927 -->
00:16:43,097
we're working on, like fixing the
networking adding API support for stacks
289
00:16:43,097 -->
00:16:47,807
or improving the CSI support because
originally when it first released two
290
00:16:47,807 -->
00:16:52,637
years ago, I was told by maintainers a
at least one maintainer, that this is
291
00:16:52,637 -->
00:16:55,307
kind of like a beta 1.0 trial thing.
292
00:16:55,307 -->
00:16:56,417
we need to put more into it.
293
00:16:56,987 -->
00:16:58,307
So where is that?
294
00:16:58,357 -->
00:16:59,197
what's happening with that?
295
00:16:59,247 -->
00:17:00,507
I'd love to see some status on that.
296
00:17:01,100 -->
00:17:04,700
with a roadmap that stretches through 2030
Mirantis is giving customers the long-term
297
00:17:04,700 -->
00:17:08,180
stability and strategic flexibility they
need to build confidently with swarm.
298
00:17:09,095 -->
00:17:11,315
We've needed that confidence for a decade.
299
00:17:11,615 -->
00:17:15,515
Docker has never had a
swarm page on their website.
300
00:17:15,725 -->
00:17:18,275
It's only mentioned in the
docs, never on the website.
301
00:17:18,275 -->
00:17:21,875
At least Mirantis has a swarm page
whether you're deploying at the
302
00:17:21,875 -->
00:17:25,325
edge in the data center or across
multi-cloud environments, MKE three
303
00:17:25,325 -->
00:17:28,295
lets you choose the right orchestrator
for the job without compromise.
304
00:17:29,195 -->
00:17:34,045
a lot of marketing fluff in there, but
essentially the key takeaway is they have
305
00:17:34,045 -->
00:17:38,785
committed to five and a half more years
of support, and they have stated publicly
306
00:17:38,785 -->
00:17:40,345
that they have swarm features coming.
307
00:17:40,765 -->
00:17:43,885
We will have to hope that those
swarm features are still in the
308
00:17:43,885 -->
00:17:45,385
open source, to my knowledge.
309
00:17:45,940 -->
00:17:47,170
Almost always is true.
310
00:17:47,320 -->
00:17:50,110
Like I'm actually having a hard
time coming up with anything other
311
00:17:50,110 -->
00:17:56,890
than compliance, military government
compliance stuff that isn't in
312
00:17:57,070 -->
00:17:58,870
ducker engine's swarm, open source.
313
00:17:58,930 -->
00:17:59,200
Right?
314
00:17:59,200 -->
00:18:04,000
So we have to kind of assume, I would
assume at this point that if any features
315
00:18:04,000 -->
00:18:08,950
or added to swarm, including improvements
to CSI, it would still roll upstream
316
00:18:09,220 -->
00:18:14,380
to Docker engine, which means all of us
swarm open source people are gonna benefit
317
00:18:14,800 -->
00:18:20,680
from the people paying mirantis for swarm
support, which is one of the best ways
318
00:18:20,680 -->
00:18:25,360
we got to maintain open source in the
in the world, is people pay for support.
319
00:18:26,470 -->
00:18:31,030
That support money drives innovation in
the open source product, which goes back
320
00:18:31,030 -->
00:18:32,890
to people using it who then want support.
321
00:18:33,190 -->
00:18:35,830
And that way has worked for a long time.
322
00:18:36,070 -->
00:18:37,330
Red Hat was built on it.
323
00:18:37,730 -->
00:18:40,840
Ubuntu, I mean, all the major
distributions, all the major
324
00:18:40,840 -->
00:18:43,750
Kubernetes distributions, including
Red Hats and ranchers and everyone
325
00:18:43,750 -->
00:18:47,440
else, they're all, they're all
built on that model of paid support.
326
00:18:47,910 -->
00:18:49,590
primarily open source.
327
00:18:49,590 -->
00:18:55,350
So, yay, we can celebrate
if you're a swarm user.
328
00:18:55,830 -->
00:19:00,480
I now am changing my opinion from
four months ago, three months ago,
329
00:19:00,940 -->
00:19:03,940
If Swarm works for you, keep doing it.
330
00:19:04,150 -->
00:19:04,960
You have my permission.
331
00:19:05,170 -->
00:19:07,060
Not that you needed it,
but you now have it.
332
00:19:07,330 -->
00:19:09,250
if you don't wanna use swarm.
333
00:19:10,015 -->
00:19:10,705
Totally fine.
334
00:19:11,185 -->
00:19:13,645
I'm not advocating for swarm everywhere.
335
00:19:13,815 -->
00:19:18,405
I don't run swarm anymore because
I'm just one person and I don't wanna
336
00:19:18,405 -->
00:19:24,535
maintain servers and patched oss and
reboot servers and replace, instances.
337
00:19:25,135 -->
00:19:25,765
I just don't.
338
00:19:26,005 -->
00:19:31,715
So I use all the cloud stuff, where I
can just run a one line command or throw
339
00:19:31,715 -->
00:19:34,905
in my container environment variables
and have it run containers natively.
340
00:19:35,305 -->
00:19:41,685
Google Cloud run, Amazon, let's see,
AWS's, 18 ways to run containers.
341
00:19:41,685 -->
00:19:44,865
Like there's all these other ways to
run containers that don't require me to
342
00:19:44,978 -->
00:19:48,158
Maintain those servers, patch
those servers, secure those
343
00:19:48,158 -->
00:19:49,448
servers, monitor those servers.
344
00:19:49,958 -->
00:19:53,888
There's so many other ways of higher
level abstraction that I do that, but it
345
00:19:53,888 -->
00:19:55,478
doesn't mean that everyone has to do that.
346
00:19:55,658 -->
00:20:00,158
And it doesn't solve on-prem problems or
edge cases where you don't have those.
347
00:20:00,438 -->
00:20:03,438
if you have very minimal needs and
you don't need the complexity of
348
00:20:03,498 -->
00:20:05,088
Kubernetes, like Swarm is back.
349
00:20:05,398 -->
00:20:06,358
Swarm is back, baby.
350
00:20:06,868 -->
00:20:07,318
It's back.
351
00:20:08,618 -->
00:20:09,848
This is the best we've ever had it.
352
00:20:10,628 -->
00:20:11,768
We have a swarm page.
353
00:20:11,888 -->
00:20:14,738
We have an actual swarm homepage.
354
00:20:15,488 -->
00:20:18,428
Docker never committed to five
years of maintaining swarm.
355
00:20:19,178 -->
00:20:23,648
Docker never stated publicly that
they even care about Swarm other
356
00:20:23,648 -->
00:20:26,498
than the original announcement
and the paid enterprise products
357
00:20:26,498 -->
00:20:27,878
that they had up until 2019.
358
00:20:27,878 -->
00:20:30,908
But ever since 2019, I've never
heard a Docker employee state
359
00:20:30,908 -->
00:20:33,788
anything publicly about Swarm
other than the fact that it exists.
360
00:20:33,838 -->
00:20:37,228
they'll confirm that it exists,
but we've never gotten certainty.
361
00:20:37,228 -->
00:20:39,938
We've never gotten commitment
from Docker, and that's all
362
00:20:39,938 -->
00:20:40,988
that people were asking for.
363
00:20:41,403 -->
00:20:44,433
they were just asking, Hey, if I
deploy this open source and yes,
364
00:20:44,433 -->
00:20:48,243
it's free, Is there some indication
that it will still exist and not be
365
00:20:48,243 -->
00:20:50,013
archived as a project in six months?
366
00:20:50,493 -->
00:20:56,003
And I think we have it like this is
the best scenario and we might be past
367
00:20:56,003 -->
00:20:58,433
the peak Kubernetes hype cycle, right?
368
00:20:58,483 -->
00:21:02,453
Some people are in that trough of
disillusionment or whatever people have
369
00:21:02,453 -->
00:21:05,453
figured out swarm and Kubernetes and they
figured out that maybe they don't need it
370
00:21:05,453 -->
00:21:07,193
all the time, or maybe they could do both.
371
00:21:07,193 -->
00:21:11,453
Maybe swarm is so simple that in some
cases I just don't deploy Kubernetes.
372
00:21:11,453 -->
00:21:13,913
Maybe I deploy some swarm
and there's no shade here.
373
00:21:13,913 -->
00:21:16,733
I'm not hating on any
product or any open source.
374
00:21:16,733 -->
00:21:18,743
this is all best effort.
375
00:21:19,958 -->
00:21:23,198
But Mirantis has given us that
level of certainty that we never
376
00:21:23,198 -->
00:21:25,388
really had with Docker, and I
really appreciate that of them.
377
00:21:25,598 -->
00:21:30,288
So what do I know in addition to those
facts, I now have multiple people inside
378
00:21:30,288 -->
00:21:35,258
of Docker and Mirantis, the companies
that work around swarm or related to
379
00:21:35,258 -->
00:21:36,848
swarm, and they're all interested in it.
380
00:21:36,848 -->
00:21:41,558
They're all curious about
the community feedback.
381
00:21:41,618 -->
00:21:45,498
So if you have contracts with any
of these companies, let them know
382
00:21:45,498 -->
00:21:46,578
that you're interested in Swarm.
383
00:21:46,638 -->
00:21:49,398
Even if you're not running it,
just tell 'em, Hey, we're always
384
00:21:49,398 -->
00:21:52,878
curious whether Swarm has added
more functionality to solve problems
385
00:21:52,878 -->
00:21:54,168
so that we don't need Kubernetes.
386
00:21:55,188 -->
00:21:59,748
Wouldn't it be wild if a decade after
Swarm was released and after Kubernetes
387
00:22:00,018 -->
00:22:04,578
rose to prominence that we all kind
of looked at Kubernetes and went,
388
00:22:04,578 -->
00:22:08,068
yeah, that's really cool and it does
really cool things, but, now that, you
389
00:22:08,068 -->
00:22:12,148
know, maybe there's budget cuts and AI
changes, some things maybe I don't need,
390
00:22:12,198 -->
00:22:15,588
All this complexity and maybe
some of the things I do, I can get
391
00:22:15,588 -->
00:22:18,928
away with simpler stuff then we
end up having a swarm resurgence.
392
00:22:19,228 -->
00:22:21,628
If you don't know the history of
Swarm with me and the relationship
393
00:22:21,628 -->
00:22:25,853
I have with it, I have two
courses that Teach Swarm on Udemy.
394
00:22:25,853 -->
00:22:28,223
So you can, in this video, you
can go down this description,
395
00:22:28,433 -->
00:22:29,783
there's a link to my courses.
396
00:22:30,053 -->
00:22:33,383
You can buy either my Docker
Mastery course, which also teaches
397
00:22:33,383 -->
00:22:38,173
swarm or the swarm course, which
has a full swarm, walkthrough.
398
00:22:38,173 -->
00:22:39,283
it's many hours of swarm.
399
00:22:39,833 -->
00:22:43,223
I've been a big fan of it for
specific simple use cases.
400
00:22:43,223 -->
00:22:45,893
I've run it myself in production
on the internet for years.
401
00:22:46,103 -->
00:22:48,593
I've helped many companies
deploy it over the years.
402
00:22:48,893 -->
00:22:51,263
Even the Old Swarm Classic, I
helped a couple of companies
403
00:22:51,263 -->
00:22:54,953
deploy that before the swarm, the
modern swarm came out swarm mode.
404
00:22:55,553 -->
00:23:01,143
So I've always been a fan of it for
people that have simple uses I'm excited
405
00:23:01,143 -->
00:23:05,103
to see that there's a team willing to
go out there on the internet and say,
406
00:23:05,153 -->
00:23:08,123
If you pay us, we will still support you.
407
00:23:08,123 -->
00:23:11,093
And we are still investing
in this open source project.
408
00:23:11,473 -->
00:23:14,483
I'm so happy that we have some clarity
on this and that there's a company
409
00:23:14,483 -->
00:23:17,933
willing to step out there, especially
considering all this AI shakeup,
410
00:23:18,243 -->
00:23:22,293
So I think a lot of vendors are just
scared to commit to anything because
411
00:23:22,443 -->
00:23:25,483
who knows where they're gonna be in 12
months, maybe all this stuff is irrelevant
412
00:23:25,483 -->
00:23:30,223
and AI DevOps becomes a thing and the AI
will just run all the Kubernetes for us.
413
00:23:30,223 -->
00:23:34,143
So we don't need other alternatives
because the AI knows Kubernetes so well
414
00:23:34,143 -->
00:23:35,973
that it makes all the hard things simpler.
415
00:23:36,306 -->
00:23:38,286
I don't know that it's gonna
solve the resource problem,
416
00:23:38,316 -->
00:23:40,285
but But you know, we can hope.
417
00:23:40,438 -->
00:23:41,248
Thanks for listening.
418
00:23:41,278 -->
00:23:42,718
And I'll see you in the next episode.
