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