‫Kubernetes or Swarm.
‫It's one of the most popular questions I get after someone
‫learns enough about orchestration to then want
‫to make a decision about which one to use.
‫I would recommend that you first
‫watch the videos on
‫Swarm, especially the very first video of that. That's Swarm
‫Mode Built-in Orchestration because again, that'll give you
‫the background on why orchestration is
‫necessary to solve certain problems. Then also watch
‫the videos previously in this section about Kubernetes so
‫that you understand the background of both tools before we
‫continue. As a baseline here, these
‫are both tools that solve similar problems. They're both
‫container orchestrators that
‫run on top of a container runtime.
‫In this video series, you have learned about the Docker
‫container runtime.
‫There are other ones now, containerd and CRI-O.
‫Really, Docker is the #1.
‫It's used in almost every case.
‫Both are backed by vendors and
‫teams of people working on the products.
‫In general, if I had to make a tweet to
‫compare the two, it would simply be that Swarm is
‫easy to build out, easy to add nodes
‫to, easy to get started, and easy to manage. So, easy is
‫definitely the one-liner thing that I would say for Swarm.
‫But, it doesn't solve all use cases where Kubernetes
‫has much more functionality, flexibility, and
‫customization. It can solve more problems, in
‫more ways, and also generally has wider adoption and
‫support.
‫For you, in order to help you decide which one you want to
‫use, we're going to go through some bullets of advantages
‫of each. I think it's important, really, for all of us if
‫you're going to be in the DevOps community and use
‫these tools to solve business problems, that you should
‫know both.
‫You should be able to install both and then deploy
‫apps on both, and know some of the basic functionality
‫around deploying apps, creating Ingress
‫options for traffic coming in, and then updating
‫those apps. I think that that alone will just get you
‫enough of familiarity with the tools so
‫that you know which one to use to solve which problems.
‫There are many advantages to each.
‫Let's break this down real quick. On the Swarm side, as
‫you've been learning throughout this course, it comes with
‫Docker. So, it's a single, vendor supported solution.
‫Which means that the container runtime, and the
‫orchestrator, are built by the same company.
‫That reaps a lot of rewards, including less
‫complexity, smaller resource usage just
‫for running the thing. Running Swarm has very little
‫resource utilization on top of Docker.
‫It's designed with the developer workflow in
‫mind. So, it's very good for Ops and
‫developers to use. Like I said, it's easy to deploy and
‫manage an orchestrator of this type.
‫It can easily grow to
‫many hundreds, if not thousands, of nodes, and you
‫won't necessarily need a large team to manage it. You might
‫say that it follows the 80/20 rule, where it
‫has 20% of the features of Kubernetes, and
‫that solves 80% of the use cases for
‫running containers and orchestration.
‫Now, that's not a scientific comparison.
‫I don't really know the exact feature number. I don't know how
‫you'd even really do that.
‫But, that seems to be the feel of it when you run both that
‫you realize that Swarm solves a majority of use
‫cases for running web apps long running solutions on
‫servers, whether it's in the Cloud or data center, or
‫even on small devices. It seems to work well
‫out-of-the-box. It has what you need. It has the
‫networking. It has the Ingress. It has the encryption.
‫All that stuff. It has the database.
‫So, out-of-the-box, it really solves a lot of problems.
‫But, it doesn't solve all the use cases, for all the
‫scenarios, to run an app on a machine.
‫That's where Kubernetes can fill the gap.
‫Another big advantage of this is that it runs wherever
‫Docker runs. Docker Engine, being six years old now
‫and the start of this whole container revolution,
‫the Engine runs in more places than any other tooling.
‫It runs not just on Linux, it runs on Windows.
‫It runs on Mainframe.
‫It runs on ARM devices, which means Embedded,
‫IoT, Raspberry Pis.
‫It runs on old ARM, new ARM, 32 bit, 64
‫bit. Like I said, it's just all over the place.
‫It runs natively on Windows Server for
‫years now since Server 2016.
‫So, it definitely is the longest supported orchestrator for
‫a diverse multi-architecture environment, if that's your
‫needs.
‫Out-of-the-box, it is secure, and you've heard me talk
‫about that in this course, that when you create
‫a Swarm and you add nodes, it ensures mutual Telus
‫authentication. It encrypts the control plane and
‫it encrypts the database to protect your
‫secrets in case you want to store those.
‫That's great because I find a lot of teams, when they're
‫rushed on deadlines or maybe they're
‫a little overwhelmed with the complexity, tend to forget or
‫skip some of the security requirements that other
‫tools like Kubernetes require. Lastly here, I believe
‫it's easier to troubleshoot because there's less moving
‫parts with it. There's less things to manage.
‫Since it's built into Docker by default, if
‫you know how to troubleshoot Docker, then you probably know
‫how to troubleshoot Swarm.
‫It uses the same daemon logs. It uses the same Docker logs
‫command for the apps. It uses the same Docker events
‫command for looking at events on the nodes
‫and the Swarm itself. Now that
‫sounds like a lot of advantages for a Swarm, but I don't
‫want you to think that that's always going to be the right
‫thing for you.
‫In general, Swarm is the tool that I recommend when
‫people start out and they're starting small.
‫Maybe they're a single person, or just one, two, or three
‫people in their team, and they
‫need to see if a small, simple orchestrator is going to
‫work for them. I always recommend Swarm first, unless you
‫know absolutely you have to use Kubernetes, I
‫do recommend Swarm. Once you think you've hit some limits
‫in Swarm and you think that you can't quite get what
‫you need out of it, that's when it's time to look at
‫Kubernetes.
‫Let's talk about some of those advantages now.
‫First up, that clouds and vendors really love to
‫support Kubernetes. Since it has become so popular, and
‫especially sort of as zeitgeist type popularity
‫in the news and the media, it is
‫something that every vendor now is looking to check off on
‫their list of we support Kubernetes.
‫So, I would say it absolutely has the widest cloud and
‫vendor support.
‫Every cloud vendor does provide an offering of Kubernetes,
‫so if you don't want to run it yourself, you can just let
‫them start all the systems up and then you're essentially
‫just running your apps on there using Kubernetes
‫deployment files. Even infrastructure vendors now
‫have their own Kubernetes distribution including VMware,
‫Red Hat. Even companies like Netflix, who is
‫traditionally just a storage vendor, has their own approved
‫version, or distribution, of Kubernetes.
‫So the obvious thing here seems to be that it has the
‫widest adoption and support, and that's definitely true.
‫But beyond that, it also has the widest set of
‫supported use cases. Since
‫it has so many more things to toggle and fiddle with, and
‫so many different features and third party options,
‫it definitely covers more of the edge cases then Swarm
‫does. In fact, you'll start seeing this with vendors you
‫probably already work with today where they will do
‫Kubernetes first support, which is my
‫way of saying that vendors will look to see how they can
‫support Kubernetes with their product before they'd bother
‫to go look at Docker's Swarm product.
‫Especially because since the industry is sort of in
‫this attitude of everything needs to support Kubernetes,
‫you're going to find that vendors you already have may
‫already have a distribution, or a solution, for running
‫their tools on Kubernetes. For example, with Jenkins,
‫from the company CloudBees.
‫If you've bought their Enterprise solution, they give you
‫Kubernetes tooling and samples on how to run it.
‫It doesn't mean you can't run Jenkins on Swarm.
‫It runs great there.
‫It just means that you're going to get better support from
‫the vendor for that.
‫The last advantage I'll mention here is sort of a weird
‫advantage. I'm going to throw up this term of
‫no one ever got fired for buying IBM.
‫Now this saying was popular decades ago when IBM
‫was the largest vendor for computing
‫and outsourcing your hardware, and your mainframes,
‫and your PCs, and there was this whole time where they
‫were really killing it in the marketplace.
‫Essentially, if you couldn't make a decision on which
‫vendor you wanted to go with. If you just went the safe
‫way, you would be going with IBM.
‫You would never really get fired for that because it was
‫the trusted vendor of the time.
‫I would say that, in general, for the Kubernetes platform
‫as a whole, that has become the case now.
‫I would argue it even has gotten to the point of being
‫a check off item for CIOs and CTOs.
‫That can be a little bit good and bad, because that can
‫mean that you will be told to run Kubernetes even
‫though you don't have technical requirements yet.
‫You're just told by your management that we need to run
‫Kubernetes. That, for them, might be just something they
‫want to run regardless of what the technical requirements,
‫or benefits are, or comparing it to different platforms.
‫That is obviously part of this political world where
‫IT decisions aren't always made on technical
‫merit or requirements alone.
‫It can often be by the ease of use of
‫buying it. In other words, if you already have a vendor
‫that has one, you might just use their product instead of
‫another one because it's easier.
‫O,r your team experience in the background might have
‫better experience from their past jobs or projects.
‫So, you're just going to deploy that one because someone
‫already knows it. Or, maybe you're going to buy it because
‫unfortunately, your management read a magazine, or read the
‫Internet, and the Internet told them they need to pick a
‫certain product like Kubernetes.
‫So, that's the one they're telling you to use.
‫In fact, when I do live workshops and I ask people
‫why they chose the orchestrator they're running, the most
‫common answer I get from them, unfortunately, is still, my
‫boss told me to do this.
‫So, people don't always get a say in what they run, which
‫is why I'm trying to give you a good balance of the tooling
‫and features of both so that you'll be the most educated
‫person in your team and be able to help them with the true
‫technical requirements and help you make the best decision.