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.