1 00:00:02,960 --> 00:00:03,960 ‫Kubernetes or Swarm. 2 00:00:05,610 --> 00:00:07,960 ‫It's one of the most popular questions I get after someone 3 00:00:07,961 --> 00:00:10,215 ‫learns enough about orchestration to then want 4 00:00:11,910 --> 00:00:12,910 ‫to make a decision about which one to use. 5 00:00:13,310 --> 00:00:14,878 ‫I would recommend that you first 6 00:00:16,270 --> 00:00:17,520 ‫watch the videos on 7 00:00:17,521 --> 00:00:18,781 ‫Swarm, especially the very first video of that. That's Swarm 8 00:00:21,100 --> 00:00:23,991 ‫Mode Built-in Orchestration because again, that'll give you 9 00:00:24,012 --> 00:00:27,159 ‫the background on why orchestration is 10 00:00:27,160 --> 00:00:30,489 ‫necessary to solve certain problems. Then also watch 11 00:00:30,490 --> 00:00:33,459 ‫the videos previously in this section about Kubernetes so 12 00:00:33,460 --> 00:00:36,040 ‫that you understand the background of both tools before we 13 00:00:36,041 --> 00:00:37,756 ‫continue. As a baseline here, these 14 00:00:39,790 --> 00:00:41,830 ‫are both tools that solve similar problems. They're both 15 00:00:41,831 --> 00:00:42,831 ‫container orchestrators that 16 00:00:46,240 --> 00:00:47,240 ‫run on top of a container runtime. 17 00:00:47,590 --> 00:00:49,989 ‫In this video series, you have learned about the Docker 18 00:00:49,990 --> 00:00:51,189 ‫container runtime. 19 00:00:51,580 --> 00:00:54,320 ‫There are other ones now, containerd and CRI-O. 20 00:00:54,770 --> 00:00:57,090 ‫Really, Docker is the #1. 21 00:00:57,120 --> 00:00:58,771 ‫It's used in almost every case. 22 00:00:58,860 --> 00:01:00,330 ‫Both are backed by vendors and 23 00:01:03,010 --> 00:01:04,112 ‫teams of people working on the products. 24 00:01:04,720 --> 00:01:06,631 ‫In general, if I had to make a tweet to 25 00:01:08,230 --> 00:01:11,559 ‫compare the two, it would simply be that Swarm is 26 00:01:11,560 --> 00:01:13,600 ‫easy to build out, easy to add nodes 27 00:01:15,160 --> 00:01:17,410 ‫to, easy to get started, and easy to manage. So, easy is 28 00:01:18,970 --> 00:01:20,809 ‫definitely the one-liner thing that I would say for Swarm. 29 00:01:21,880 --> 00:01:24,903 ‫But, it doesn't solve all use cases where Kubernetes 30 00:01:25,570 --> 00:01:28,779 ‫has much more functionality, flexibility, and 31 00:01:28,780 --> 00:01:31,849 ‫customization. It can solve more problems, in 32 00:01:31,850 --> 00:01:34,398 ‫more ways, and also generally has wider adoption and 33 00:01:35,260 --> 00:01:36,260 ‫support. 34 00:01:36,880 --> 00:01:39,722 ‫For you, in order to help you decide which one you want to 35 00:01:39,791 --> 00:01:42,584 ‫use, we're going to go through some bullets of advantages 36 00:01:42,641 --> 00:01:45,434 ‫of each. I think it's important, really, for all of us if 37 00:01:46,210 --> 00:01:49,269 ‫you're going to be in the DevOps community and use 38 00:01:49,270 --> 00:01:51,640 ‫these tools to solve business problems, that you should 39 00:01:51,641 --> 00:01:52,641 ‫know both. 40 00:01:53,100 --> 00:01:55,550 ‫You should be able to install both and then deploy 41 00:01:56,470 --> 00:01:58,634 ‫apps on both, and know some of the basic functionality 42 00:01:58,635 --> 00:02:01,749 ‫around deploying apps, creating Ingress 43 00:02:01,750 --> 00:02:04,102 ‫options for traffic coming in, and then updating 44 00:02:05,110 --> 00:02:07,369 ‫those apps. I think that that alone will just get you 45 00:02:07,370 --> 00:02:10,779 ‫enough of familiarity with the tools so 46 00:02:10,780 --> 00:02:13,650 ‫that you know which one to use to solve which problems. 47 00:02:13,889 --> 00:02:15,844 ‫There are many advantages to each. 48 00:02:16,770 --> 00:02:18,999 ‫Let's break this down real quick. On the Swarm side, as 49 00:02:19,000 --> 00:02:21,521 ‫you've been learning throughout this course, it comes with 50 00:02:21,522 --> 00:02:24,020 ‫Docker. So, it's a single, vendor supported solution. 51 00:02:24,270 --> 00:02:26,573 ‫Which means that the container runtime, and the 52 00:02:27,100 --> 00:02:28,894 ‫orchestrator, are built by the same company. 53 00:02:28,970 --> 00:02:32,889 ‫That reaps a lot of rewards, including less 54 00:02:32,890 --> 00:02:34,801 ‫complexity, smaller resource usage just 55 00:02:36,130 --> 00:02:37,993 ‫for running the thing. Running Swarm has very little 56 00:02:37,994 --> 00:02:39,702 ‫resource utilization on top of Docker. 57 00:02:39,703 --> 00:02:41,859 ‫It's designed with the developer workflow in 58 00:02:42,910 --> 00:02:44,674 ‫mind. So, it's very good for Ops and 59 00:02:46,240 --> 00:02:48,935 ‫developers to use. Like I said, it's easy to deploy and 60 00:02:49,840 --> 00:02:52,301 ‫manage an orchestrator of this type. 61 00:02:52,680 --> 00:02:53,761 ‫It can easily grow to 62 00:02:55,810 --> 00:02:56,860 ‫many hundreds, if not thousands, of nodes, and you 63 00:02:58,960 --> 00:03:00,400 ‫won't necessarily need a large team to manage it. You might 64 00:03:00,401 --> 00:03:03,669 ‫say that it follows the 80/20 rule, where it 65 00:03:03,670 --> 00:03:06,879 ‫has 20% of the features of Kubernetes, and 66 00:03:06,880 --> 00:03:08,644 ‫that solves 80% of the use cases for 67 00:03:10,270 --> 00:03:11,270 ‫running containers and orchestration. 68 00:03:11,530 --> 00:03:13,171 ‫Now, that's not a scientific comparison. 69 00:03:14,790 --> 00:03:16,149 ‫I don't really know the exact feature number. I don't know how 70 00:03:16,150 --> 00:03:17,251 ‫you'd even really do that. 71 00:03:18,010 --> 00:03:20,901 ‫But, that seems to be the feel of it when you run both that 72 00:03:21,610 --> 00:03:23,870 ‫you realize that Swarm solves a majority of use 73 00:03:25,810 --> 00:03:28,358 ‫cases for running web apps long running solutions on 74 00:03:28,900 --> 00:03:31,497 ‫servers, whether it's in the Cloud or data center, or 75 00:03:31,990 --> 00:03:33,852 ‫even on small devices. It seems to work well 76 00:03:34,390 --> 00:03:36,309 ‫out-of-the-box. It has what you need. It has the 77 00:03:36,310 --> 00:03:38,379 ‫networking. It has the Ingress. It has the encryption. 78 00:03:38,390 --> 00:03:40,472 ‫All that stuff. It has the database. 79 00:03:40,830 --> 00:03:43,415 ‫So, out-of-the-box, it really solves a lot of problems. 80 00:03:43,570 --> 00:03:47,619 ‫But, it doesn't solve all the use cases, for all the 81 00:03:47,620 --> 00:03:48,620 ‫scenarios, to run an app on a machine. 82 00:03:49,072 --> 00:03:51,243 ‫That's where Kubernetes can fill the gap. 83 00:03:51,790 --> 00:03:54,436 ‫Another big advantage of this is that it runs wherever 84 00:03:54,580 --> 00:03:57,669 ‫Docker runs. Docker Engine, being six years old now 85 00:03:57,910 --> 00:04:00,522 ‫and the start of this whole container revolution, 86 00:04:01,310 --> 00:04:03,794 ‫the Engine runs in more places than any other tooling. 87 00:04:04,080 --> 00:04:06,334 ‫It runs not just on Linux, it runs on Windows. 88 00:04:06,740 --> 00:04:07,931 ‫It runs on Mainframe. 89 00:04:08,080 --> 00:04:11,030 ‫It runs on ARM devices, which means Embedded, 90 00:04:11,040 --> 00:04:13,650 ‫IoT, Raspberry Pis. 91 00:04:14,070 --> 00:04:17,010 ‫It runs on old ARM, new ARM, 32 bit, 64 92 00:04:18,010 --> 00:04:20,402 ‫bit. Like I said, it's just all over the place. 93 00:04:20,610 --> 00:04:22,472 ‫It runs natively on Windows Server for 94 00:04:23,920 --> 00:04:25,089 ‫years now since Server 2016. 95 00:04:26,290 --> 00:04:29,181 ‫So, it definitely is the longest supported orchestrator for 96 00:04:29,740 --> 00:04:32,411 ‫a diverse multi-architecture environment, if that's your 97 00:04:32,412 --> 00:04:33,412 ‫needs. 98 00:04:33,820 --> 00:04:35,893 ‫Out-of-the-box, it is secure, and you've heard me talk 99 00:04:35,894 --> 00:04:38,197 ‫about that in this course, that when you create 100 00:04:38,890 --> 00:04:42,190 ‫a Swarm and you add nodes, it ensures mutual Telus 101 00:04:42,320 --> 00:04:45,879 ‫authentication. It encrypts the control plane and 102 00:04:45,880 --> 00:04:47,840 ‫it encrypts the database to protect your 103 00:04:48,850 --> 00:04:50,139 ‫secrets in case you want to store those. 104 00:04:50,390 --> 00:04:53,134 ‫That's great because I find a lot of teams, when they're 105 00:04:53,230 --> 00:04:54,551 ‫rushed on deadlines or maybe they're 106 00:04:56,350 --> 00:04:58,299 ‫a little overwhelmed with the complexity, tend to forget or 107 00:04:58,300 --> 00:05:01,689 ‫skip some of the security requirements that other 108 00:05:01,690 --> 00:05:04,630 ‫tools like Kubernetes require. Lastly here, I believe 109 00:05:04,870 --> 00:05:07,565 ‫it's easier to troubleshoot because there's less moving 110 00:05:07,633 --> 00:05:09,483 ‫parts with it. There's less things to manage. 111 00:05:09,640 --> 00:05:11,770 ‫Since it's built into Docker by default, if 112 00:05:13,690 --> 00:05:15,669 ‫you know how to troubleshoot Docker, then you probably know 113 00:05:15,670 --> 00:05:16,710 ‫how to troubleshoot Swarm. 114 00:05:17,560 --> 00:05:20,402 ‫It uses the same daemon logs. It uses the same Docker logs 115 00:05:20,460 --> 00:05:23,559 ‫command for the apps. It uses the same Docker events 116 00:05:23,560 --> 00:05:26,710 ‫command for looking at events on the nodes 117 00:05:26,720 --> 00:05:28,190 ‫and the Swarm itself. Now that 118 00:05:30,040 --> 00:05:32,620 ‫sounds like a lot of advantages for a Swarm, but I don't 119 00:05:32,621 --> 00:05:34,512 ‫want you to think that that's always going to be the right 120 00:05:34,513 --> 00:05:34,807 ‫thing for you. 121 00:05:34,808 --> 00:05:37,356 ‫In general, Swarm is the tool that I recommend when 122 00:05:37,860 --> 00:05:39,841 ‫people start out and they're starting small. 123 00:05:40,070 --> 00:05:42,809 ‫Maybe they're a single person, or just one, two, or three 124 00:05:42,810 --> 00:05:45,759 ‫people in their team, and they 125 00:05:45,760 --> 00:05:48,129 ‫need to see if a small, simple orchestrator is going to 126 00:05:48,130 --> 00:05:50,570 ‫work for them. I always recommend Swarm first, unless you 127 00:05:50,571 --> 00:05:52,776 ‫know absolutely you have to use Kubernetes, I 128 00:05:54,460 --> 00:05:56,469 ‫do recommend Swarm. Once you think you've hit some limits 129 00:05:56,470 --> 00:05:59,018 ‫in Swarm and you think that you can't quite get what 130 00:05:59,800 --> 00:06:01,145 ‫you need out of it, that's when it's time to look at 131 00:06:01,380 --> 00:06:02,380 ‫Kubernetes. 132 00:06:03,400 --> 00:06:04,400 ‫Let's talk about some of those advantages now. 133 00:06:05,350 --> 00:06:08,499 ‫First up, that clouds and vendors really love to 134 00:06:08,500 --> 00:06:11,009 ‫support Kubernetes. Since it has become so popular, and 135 00:06:11,010 --> 00:06:13,313 ‫especially sort of as zeitgeist type popularity 136 00:06:15,130 --> 00:06:16,698 ‫in the news and the media, it is 137 00:06:18,220 --> 00:06:20,259 ‫something that every vendor now is looking to check off on 138 00:06:20,260 --> 00:06:21,260 ‫their list of we support Kubernetes. 139 00:06:21,610 --> 00:06:24,779 ‫So, I would say it absolutely has the widest cloud and 140 00:06:24,790 --> 00:06:25,790 ‫vendor support. 141 00:06:26,500 --> 00:06:29,370 ‫Every cloud vendor does provide an offering of Kubernetes, 142 00:06:29,600 --> 00:06:32,393 ‫so if you don't want to run it yourself, you can just let 143 00:06:32,650 --> 00:06:34,960 ‫them start all the systems up and then you're essentially 144 00:06:34,961 --> 00:06:37,548 ‫just running your apps on there using Kubernetes 145 00:06:38,520 --> 00:06:40,921 ‫deployment files. Even infrastructure vendors now 146 00:06:41,860 --> 00:06:45,079 ‫have their own Kubernetes distribution including VMware, 147 00:06:45,470 --> 00:06:47,626 ‫Red Hat. Even companies like Netflix, who is 148 00:06:48,850 --> 00:06:51,699 ‫traditionally just a storage vendor, has their own approved 149 00:06:51,700 --> 00:06:54,210 ‫version, or distribution, of Kubernetes. 150 00:06:54,960 --> 00:06:57,557 ‫So the obvious thing here seems to be that it has the 151 00:06:57,794 --> 00:07:00,541 ‫widest adoption and support, and that's definitely true. 152 00:07:01,540 --> 00:07:03,794 ‫But beyond that, it also has the widest set of 153 00:07:04,720 --> 00:07:05,720 ‫supported use cases. Since 154 00:07:08,500 --> 00:07:10,980 ‫it has so many more things to toggle and fiddle with, and 155 00:07:10,990 --> 00:07:12,823 ‫so many different features and third party options, 156 00:07:13,649 --> 00:07:16,128 ‫it definitely covers more of the edge cases then Swarm 157 00:07:16,420 --> 00:07:19,164 ‫does. In fact, you'll start seeing this with vendors you 158 00:07:20,100 --> 00:07:22,281 ‫probably already work with today where they will do 159 00:07:22,570 --> 00:07:24,383 ‫Kubernetes first support, which is my 160 00:07:25,590 --> 00:07:28,334 ‫way of saying that vendors will look to see how they can 161 00:07:28,650 --> 00:07:31,949 ‫support Kubernetes with their product before they'd bother 162 00:07:31,950 --> 00:07:33,300 ‫to go look at Docker's Swarm product. 163 00:07:34,100 --> 00:07:36,599 ‫Especially because since the industry is sort of in 164 00:07:37,470 --> 00:07:38,932 ‫this attitude of everything needs to support Kubernetes, 165 00:07:39,440 --> 00:07:42,090 ‫you're going to find that vendors you already have may 166 00:07:43,740 --> 00:07:46,350 ‫already have a distribution, or a solution, for running 167 00:07:46,351 --> 00:07:49,290 ‫their tools on Kubernetes. For example, with Jenkins, 168 00:07:49,310 --> 00:07:50,500 ‫from the company CloudBees. 169 00:07:51,450 --> 00:07:54,080 ‫If you've bought their Enterprise solution, they give you 170 00:07:54,300 --> 00:07:57,249 ‫Kubernetes tooling and samples on how to run it. 171 00:07:57,400 --> 00:07:59,840 ‫It doesn't mean you can't run Jenkins on Swarm. 172 00:08:00,290 --> 00:08:01,290 ‫It runs great there. 173 00:08:01,990 --> 00:08:04,083 ‫It just means that you're going to get better support from 174 00:08:04,084 --> 00:08:05,084 ‫the vendor for that. 175 00:08:05,560 --> 00:08:08,029 ‫The last advantage I'll mention here is sort of a weird 176 00:08:08,030 --> 00:08:10,880 ‫advantage. I'm going to throw up this term of 177 00:08:11,000 --> 00:08:12,919 ‫no one ever got fired for buying IBM. 178 00:08:13,280 --> 00:08:16,339 ‫Now this saying was popular decades ago when IBM 179 00:08:16,340 --> 00:08:19,699 ‫was the largest vendor for computing 180 00:08:19,700 --> 00:08:23,089 ‫and outsourcing your hardware, and your mainframes, 181 00:08:23,090 --> 00:08:26,089 ‫and your PCs, and there was this whole time where they 182 00:08:26,090 --> 00:08:27,980 ‫were really killing it in the marketplace. 183 00:08:28,250 --> 00:08:30,559 ‫Essentially, if you couldn't make a decision on which 184 00:08:30,560 --> 00:08:33,139 ‫vendor you wanted to go with. If you just went the safe 185 00:08:33,140 --> 00:08:35,617 ‫way, you would be going with IBM. 186 00:08:35,840 --> 00:08:38,269 ‫You would never really get fired for that because it was 187 00:08:38,270 --> 00:08:39,830 ‫the trusted vendor of the time. 188 00:08:40,309 --> 00:08:42,918 ‫I would say that, in general, for the Kubernetes platform 189 00:08:42,919 --> 00:08:45,350 ‫as a whole, that has become the case now. 190 00:08:45,650 --> 00:08:48,679 ‫I would argue it even has gotten to the point of being 191 00:08:48,710 --> 00:08:51,151 ‫a check off item for CIOs and CTOs. 192 00:08:52,040 --> 00:08:54,229 ‫That can be a little bit good and bad, because that can 193 00:08:54,230 --> 00:08:56,631 ‫mean that you will be told to run Kubernetes even 194 00:08:57,200 --> 00:08:58,833 ‫though you don't have technical requirements yet. 195 00:08:58,887 --> 00:09:01,940 ‫You're just told by your management that we need to run 196 00:09:02,270 --> 00:09:04,999 ‫Kubernetes. That, for them, might be just something they 197 00:09:05,000 --> 00:09:08,209 ‫want to run regardless of what the technical requirements, 198 00:09:08,450 --> 00:09:11,480 ‫or benefits are, or comparing it to different platforms. 199 00:09:11,960 --> 00:09:15,169 ‫That is obviously part of this political world where 200 00:09:15,650 --> 00:09:19,009 ‫IT decisions aren't always made on technical 201 00:09:19,010 --> 00:09:20,659 ‫merit or requirements alone. 202 00:09:20,930 --> 00:09:22,743 ‫It can often be by the ease of use of 203 00:09:23,900 --> 00:09:26,030 ‫buying it. In other words, if you already have a vendor 204 00:09:26,060 --> 00:09:28,853 ‫that has one, you might just use their product instead of 205 00:09:29,090 --> 00:09:30,499 ‫another one because it's easier. 206 00:09:30,920 --> 00:09:33,649 ‫O,r your team experience in the background might have 207 00:09:33,650 --> 00:09:36,320 ‫better experience from their past jobs or projects. 208 00:09:36,650 --> 00:09:39,319 ‫So, you're just going to deploy that one because someone 209 00:09:39,320 --> 00:09:42,260 ‫already knows it. Or, maybe you're going to buy it because 210 00:09:42,470 --> 00:09:44,989 ‫unfortunately, your management read a magazine, or read the 211 00:09:44,990 --> 00:09:47,239 ‫Internet, and the Internet told them they need to pick a 212 00:09:47,240 --> 00:09:48,440 ‫certain product like Kubernetes. 213 00:09:49,070 --> 00:09:50,809 ‫So, that's the one they're telling you to use. 214 00:09:51,560 --> 00:09:54,234 ‫In fact, when I do live workshops and I ask people 215 00:09:54,770 --> 00:09:57,319 ‫why they chose the orchestrator they're running, the most 216 00:09:57,320 --> 00:10:00,409 ‫common answer I get from them, unfortunately, is still, my 217 00:10:00,410 --> 00:10:01,789 ‫boss told me to do this. 218 00:10:02,030 --> 00:10:04,948 ‫So, people don't always get a say in what they run, which 219 00:10:05,660 --> 00:10:08,509 ‫is why I'm trying to give you a good balance of the tooling 220 00:10:08,510 --> 00:10:11,839 ‫and features of both so that you'll be the most educated 221 00:10:11,840 --> 00:10:14,239 ‫person in your team and be able to help them with the true 222 00:10:14,240 --> 00:10:17,660 ‫technical requirements and help you make the best decision.