Kubernetes or Swarm. 2 2
It's one of the most popular questions I get after someone 3 3
learns enough about orchestration to then want 4 4
to make a decision about which one to use. 5 5
I would recommend that you first 6 6
watch the videos on 7 7
Swarm, especially the very first video of that. That's Swarm 8 8
Mode Built-in Orchestration because again, that'll give you 9 9
the background on why orchestration is 10 10
necessary to solve certain problems. Then also watch 11 11
the videos previously in this section about Kubernetes so 12 12
that you understand the background of both tools before we 13 13
continue. As a baseline here, these 14 14
are both tools that solve similar problems. They're both 15 15
container orchestrators that 16 16
run on top of a container runtime. 17 17
In this video series, you have learned about the Docker 18 18
container runtime. 19 19
There are other ones now, containerd and CRI-O. 20 20
Really, Docker is the #1. 21 21
It's used in almost every case. 22 22
Both are backed by vendors and 23 23
teams of people working on the products. 24 24
In general, if I had to make a tweet to 25 25
compare the two, it would simply be that Swarm is 26 26
easy to build out, easy to add nodes 27 27
to, easy to get started, and easy to manage. So, easy is 28 28
definitely the one-liner thing that I would say for Swarm. 29 29
But, it doesn't solve all use cases where Kubernetes 30 30
has much more functionality, flexibility, and 31 31
customization. It can solve more problems, in 32 32
more ways, and also generally has wider adoption and 33 33
support. 34 34
For you, in order to help you decide which one you want to 35 35
use, we're going to go through some bullets of advantages 36 36
of each. I think it's important, really, for all of us if 37 37
you're going to be in the DevOps community and use 38 38
these tools to solve business problems, that you should 39 39
know both. 40 40
You should be able to install both and then deploy 41 41
apps on both, and know some of the basic functionality 42 42
around deploying apps, creating Ingress 43 43
options for traffic coming in, and then updating 44 44
those apps. I think that that alone will just get you 45 45
enough of familiarity with the tools so 46 46
that you know which one to use to solve which problems. 47 47
There are many advantages to each. 48 48
Let's break this down real quick. On the Swarm side, as 49 49
you've been learning throughout this course, it comes with 50 50
Docker. So, it's a single, vendor supported solution. 51 51
Which means that the container runtime, and the 52 52
orchestrator, are built by the same company. 53 53
That reaps a lot of rewards, including less 54 54
complexity, smaller resource usage just 55 55
for running the thing. Running Swarm has very little 56 56
resource utilization on top of Docker. 57 57
It's designed with the developer workflow in 58 58
mind. So, it's very good for Ops and 59 59
developers to use. Like I said, it's easy to deploy and 60 60
manage an orchestrator of this type. 61 61
It can easily grow to 62 62
many hundreds, if not thousands, of nodes, and you 63 63
won't necessarily need a large team to manage it. You might 64 64
say that it follows the 80/20 rule, where it 65 65
has 20% of the features of Kubernetes, and 66 66
that solves 80% of the use cases for 67 67
running containers and orchestration. 68 68
Now, that's not a scientific comparison. 69 69
I don't really know the exact feature number. I don't know how 70 70
you'd even really do that. 71 71
But, that seems to be the feel of it when you run both that 72 72
you realize that Swarm solves a majority of use 73 73
cases for running web apps long running solutions on 74 74
servers, whether it's in the Cloud or data center, or 75 75
even on small devices. It seems to work well 76 76
out-of-the-box. It has what you need. It has the 77 77
networking. It has the Ingress. It has the encryption. 78 78
All that stuff. It has the database. 79 79
So, out-of-the-box, it really solves a lot of problems. 80 80
But, it doesn't solve all the use cases, for all the 81 81
scenarios, to run an app on a machine. 82 82
That's where Kubernetes can fill the gap. 83 83
Another big advantage of this is that it runs wherever 84 84
Docker runs. Docker Engine, being six years old now 85 85
and the start of this whole container revolution, 86 86
the Engine runs in more places than any other tooling. 87 87
It runs not just on Linux, it runs on Windows. 88 88
It runs on Mainframe. 89 89
It runs on ARM devices, which means Embedded, 90 90
IoT, Raspberry Pis. 91 91
It runs on old ARM, new ARM, 32 bit, 64 92 92
bit. Like I said, it's just all over the place. 93 93
It runs natively on Windows Server for 94 94
years now since Server 2016. 95 95
So, it definitely is the longest supported orchestrator for 96 96
a diverse multi-architecture environment, if that's your 97 97
needs. 98 98
Out-of-the-box, it is secure, and you've heard me talk 99 99
about that in this course, that when you create 100 100
a Swarm and you add nodes, it ensures mutual Telus 101 101
authentication. It encrypts the control plane and 102 102
it encrypts the database to protect your 103 103
secrets in case you want to store those. 104 104
That's great because I find a lot of teams, when they're 105 105
rushed on deadlines or maybe they're 106 106
a little overwhelmed with the complexity, tend to forget or 107 107
skip some of the security requirements that other 108 108
tools like Kubernetes require. Lastly here, I believe 109 109
it's easier to troubleshoot because there's less moving 110 110
parts with it. There's less things to manage. 111 111
Since it's built into Docker by default, if 112 112
you know how to troubleshoot Docker, then you probably know 113 113
how to troubleshoot Swarm. 114 114
It uses the same daemon logs. It uses the same Docker logs 115 115
command for the apps. It uses the same Docker events 116 116
command for looking at events on the nodes 117 117
and the Swarm itself. Now that 118 118
sounds like a lot of advantages for a Swarm, but I don't 119 119
want you to think that that's always going to be the right 120 120
thing for you. 121 121
In general, Swarm is the tool that I recommend when 122 122
people start out and they're starting small. 123 123
Maybe they're a single person, or just one, two, or three 124 124
people in their team, and they 125 125
need to see if a small, simple orchestrator is going to 126 126
work for them. I always recommend Swarm first, unless you 127 127
know absolutely you have to use Kubernetes, I 128 128
do recommend Swarm. Once you think you've hit some limits 129 129
in Swarm and you think that you can't quite get what 130 130
you need out of it, that's when it's time to look at 131 131
Kubernetes. 132 132
Let's talk about some of those advantages now. 133 133
First up, that clouds and vendors really love to 134 134
support Kubernetes. Since it has become so popular, and 135 135
especially sort of as zeitgeist type popularity 136 136
in the news and the media, it is 137 137
something that every vendor now is looking to check off on 138 138
their list of we support Kubernetes. 139 139
So, I would say it absolutely has the widest cloud and 140 140
vendor support. 141 141
Every cloud vendor does provide an offering of Kubernetes, 142 142
so if you don't want to run it yourself, you can just let 143 143
them start all the systems up and then you're essentially 144 144
just running your apps on there using Kubernetes 145 145
deployment files. Even infrastructure vendors now 146 146
have their own Kubernetes distribution including VMware, 147 147
Red Hat. Even companies like Netflix, who is 148 148
traditionally just a storage vendor, has their own approved 149 149
version, or distribution, of Kubernetes. 150 150
So the obvious thing here seems to be that it has the 151 151
widest adoption and support, and that's definitely true. 152 152
But beyond that, it also has the widest set of 153 153
supported use cases. Since 154 154
it has so many more things to toggle and fiddle with, and 155 155
so many different features and third party options, 156 156
it definitely covers more of the edge cases then Swarm 157 157
does. In fact, you'll start seeing this with vendors you 158 158
probably already work with today where they will do 159 159
Kubernetes first support, which is my 160 160
way of saying that vendors will look to see how they can 161 161
support Kubernetes with their product before they'd bother 162 162
to go look at Docker's Swarm product. 163 163
Especially because since the industry is sort of in 164 164
this attitude of everything needs to support Kubernetes, 165 165
you're going to find that vendors you already have may 166 166
already have a distribution, or a solution, for running 167 167
their tools on Kubernetes. For example, with Jenkins, 168 168
from the company CloudBees. 169 169
If you've bought their Enterprise solution, they give you 170 170
Kubernetes tooling and samples on how to run it. 171 171
It doesn't mean you can't run Jenkins on Swarm. 172 172
It runs great there. 173 173
It just means that you're going to get better support from 174 174
the vendor for that. 175 175
The last advantage I'll mention here is sort of a weird 176 176
advantage. I'm going to throw up this term of 177 177
no one ever got fired for buying IBM. 178 178
Now this saying was popular decades ago when IBM 179 179
was the largest vendor for computing 180 180
and outsourcing your hardware, and your mainframes, 181 181
and your PCs, and there was this whole time where they 182 182
were really killing it in the marketplace. 183 183
Essentially, if you couldn't make a decision on which 184 184
vendor you wanted to go with. If you just went the safe 185 185
way, you would be going with IBM. 186 186
You would never really get fired for that because it was 187 187
the trusted vendor of the time. 188 188
I would say that, in general, for the Kubernetes platform 189 189
as a whole, that has become the case now. 190 190
I would argue it even has gotten to the point of being 191 191
a check off item for CIOs and CTOs. 192 192
That can be a little bit good and bad, because that can 193 193
mean that you will be told to run Kubernetes even 194 194
though you don't have technical requirements yet. 195 195
You're just told by your management that we need to run 196 196
Kubernetes. That, for them, might be just something they 197 197
want to run regardless of what the technical requirements, 198 198
or benefits are, or comparing it to different platforms. 199 199
That is obviously part of this political world where 200 200
IT decisions aren't always made on technical 201 201
merit or requirements alone. 202 202
It can often be by the ease of use of 203 203
buying it. In other words, if you already have a vendor 204 204
that has one, you might just use their product instead of 205 205
another one because it's easier. 206 206
O,r your team experience in the background might have 207 207
better experience from their past jobs or projects. 208 208
So, you're just going to deploy that one because someone 209 209
already knows it. Or, maybe you're going to buy it because 210 210
unfortunately, your management read a magazine, or read the 211 211
Internet, and the Internet told them they need to pick a 212 212
certain product like Kubernetes. 213 213
So, that's the one they're telling you to use. 214 214
In fact, when I do live workshops and I ask people 215 215
why they chose the orchestrator they're running, the most 216 216
common answer I get from them, unfortunately, is still, my 217 217
boss told me to do this. 218 218
So, people don't always get a say in what they run, which 219 219
is why I'm trying to give you a good balance of the tooling 220 220
and features of both so that you'll be the most educated 221 221
person in your team and be able to help them with the true 222 222
technical requirements and help you make the best decision.