>>welcome to the session. Long live swarm with containers and kubernetes everywhere we have this increasing cloud complexity at the same time that we're facing economic uncertainty and, of course, to navigate this. For most companies, it's a matter of focusing on speed and on shipping and iterating their code faster. Now. For many, Marantz is customers. That means using docker swarm rather than kubernetes to handle container orchestration. We really believe that the best way to increase your speed to production is choice, simplicity and security. So we wanted to bring you a couple of experts to talk about the state of swarm and Docker enterprise and how you can make best use of both of you. So let's get to it. Well, good afternoon or good morning, depending on where you are on and welcome to today's session. Long live swarm. I am Nick Chase. I'm head of content here at Mantis and I would like to introduce you to our two Panelists today eight of Manzini. Why don't you introduce yourself? >>I am a van CNI. I'm a solutions architect here at Moran Tous on work primarily with Docker Enterprise System. I have a long history of working with support team. Um, at what used to be Ah Docker Enterprise, part of Docker Inc. >>Yeah, Okay. Great. And Don Power. >>I, um Yeah, I'm Don Power on the docker. Captain Docker, community leader. Right now I run our Dev Ops team for Citizens Bank out of Nashville, Tennessee, and happy to be here. >>All right, Excellent. So All right, so thank you both for coming. Now, before we say anything else, I want to go ahead and kind of name the elephant in the room. There's been a lot of talk about the >>future. Yeah, that's right. Um, swarm as it stands right now, um, we have, ah, very vested interest in keeping our customers on who want to continue using swarm, functional and keeping swarm a viable alternative or complement to kubernetes. However you see the orchestration war playing out as it were. >>Okay? It's hardly a war at this point, but they do work together, and so that's >>absolutely Yeah, I I definitely consider them more of like, complimentary services, um, using the right tool for the job. Sort of sense. They both have different design goals when they were originally created and set out so I definitely don't see it as a completely one or the other kind of decision and that they could both be used in the same environment and similar clusters to run whatever workload that you have. >>Excellent. And we'll get into the details of all that as we go along. So that's terrific. So I have not really been involved in in the sort of swarm area. So set the stage for us where we kind of start out with all of this. Don I know that you were involved and so guys said, set the stage for us. >>Sure, Um I mean so I've been a heavy user of swarm in my past few roles. Professionally, we've been running containers in production with Swarm for coming up on about four years. Now, Um, in our case, we you know, we looked at what was available at the time, and of course you had. Kubernetes is your biggest contender out there, but like I just mentioned, the one of the things that really led us to swarm is it's design goals were very different than kubernetes. So Kubernetes tries to have an answer for absolutely every scenario where swarm tries to have an answer for, like, the 80% of problems or challenges will say that you might come across 80% of the workloads. Um, I had a better way of saying that, but I think I got my point across >>E Yeah, I think I think you hit the nail on the head. Um, Kubernetes in particular with the way that kubernetes itself is an a P I I believe that kubernetes was, um, you know, written as a toolkit. It wasn't really intended to be used by end users directly. It was really a way to build platforms that run containers. And because it's this really, really extensible ap I you can extend it to manage all sorts of resource is swarm doesn't have that X sensibility aspect, but what it was designed to do, it does very, very well and very easily in a very, very simple sort of way. Um, it's highly opinionated about the way that you should use the product, but it works very effectively. It's very easy to use. It's very low. Um, not low effort, but low. Ah, low barrier to entry. >>Yes. Yes. Absolutely. I was gonna touch on the same thing. It's very easy for someone to come in. Pick up swarm. You know they don't They don't have to know anything about the orchestrator on day one. Most people that are getting into this space are very familiar with Docker. Compose um, and entering from Docker compose into swarm is changing one command that you would run on the command line. >>Yeah, very, very trivial to if you are already used to building docker files using composed, organize your deployment into stacks of related components. It's trivial to turn on swarm mode and then deploy your container set to a cluster. >>Well, excellent. So answer this question for me. Is the swarm of today the same as the swarm of, you know, the original swarm. So, like when swim first started is that the same is what we have now >>it's kind of ah, complicated story with the storm project because it's changed names and forms a few times. Originally in is really somewhere around 2014 in the first version, and it was a component that you really had to configure and set up separately from Docker Ah, the way that it was structured. Ah, you would just have docker installed on a number of servers are machines in your cluster. And then you would organize them into a swarm by bringing your own database and some of the tooling to get those nodes talking to each other and to organize your containers across all of your docker engines. Ah, few years later, the swarm project was retooled and baked into the docker engine. And, um, this is where we sort of get the name change from. So originally it was a feature that we called swarm. Ah. Then the Swarm Kit project was released on Get Hub and baked directly into the engine, where they renamed it as swarm mode. Because now it is a motile option that you just turn on as a button in the docker engine and because it's already there the, um, the tuning knobs that you haven't swarm kit with regard to how what my time outs are and some of these other sort of performance settings there locked there, they're there. It's part of the opinionated set of components that builds up the docker engine is that we bring in the Swarm Kit project with a certain set of defaults and settings. And that is how it operates in today's version of Docker engine. >>Uh, okay for that, that makes sense. That makes sense. So ah, so don, I know you have pretty strong feelings about this topic, but it is swarm still viable in a world that's sort of increasingly dominated by Kubernetes. >>Absolutely. And you were right. I'm very passionate about this topic where I work. We're we're doing almost all of our production work lives on swarm we only have out of Ah, we've got something like 600 different services between three and 4000 containers. At any given point in time. Out of all of those projects, all of those services we've only run into two or three that don't kind of fit into the opinionated model of swarm. So we are running those on KUBERNETES in the same cluster using Moranis is Docker enterprise offering. But, um, no, that's a very, very small percentage of services that we didn't have an answer for in swarm with one. The one case that really gets us just about every time is scaling state full services. But you're gonna have very few staple services in most environments for things like micro service architecture, which is predominantly what we build out. Swarm is perfect. It's simple. It's easy to use you, don't you? Don't end up going for miles of yamma files trying to figure out the one setting that you didn't get exactly right? Um yeah, the other Thea the other big piece of it that way really led us to adopting it so heavily in the beginning is, you know, the overlay network. So your networks don't have to span the whole cluster like they do with kubernetes. So we could we could set up a network isolation between service A and service B, just by use using the built in overlay networks. That was a huge component that, like I said, let us Teoh adopting it so heavily when we first got started. >>Excellent. You look like you're about to say something in a >>Yeah, I think that speaks to the design goals for each piece of software. On the way that I've heard this described before is with regard to the networking piece the ah, the docker networking under the hood, um, feels like it was written by a network engineer. The way that the docker engine overlay networks communicate uses ah, VX lan under the hood, which creates pseudo V lands for your containers. And if two containers aren't on the same Dylan, there's no way they can communicate with each other as opposed to the design of kubernetes networking, which is really left to the C and I implementation but still has the design philosophy of one big, flat sub net where every I p could reach every other i p and you control what is allowed to access, what by policy. So it's more of an application focused Ah design. Whereas in Docker swarm on the overlay networking side, it's really of a network engineering sort of focus. Right? >>Okay, got it. Well, so now how does all this fit in with Docker enterprise now? So I understand there's been some changes on how swarm is handled within Docker Enterprise. Coming with this new release, >>Docker s O swarm Inside Docker Enterprise is represented as both the swarm classic legacy system that we shift way back in 2014 on and then also the swarm mode that is curly used in the docker engine. Um, the Swarm Classic back end gives us legacy support for being able to run unmanaged plane containers onto a cluster. If you were to take Docker ce right now, you would find that you wouldn't be able to just do a very basic docker run against a whole cluster of machines. You can create services using the swarms services, a p I but, um, that that legacy plane container support is something that you have to set up external swarm in order to provide. So right now, the architecture of Docker Enterprise UCP is based on some of that legacy code from about five or six years ago. Okay. Ah, that gives us ability to deploy plane containers for use cases that require it as well as swarm services for those kinds of workloads that might be better served by the built in load balancing and h A and scaling features that swarm provides. >>Okay, so now I know that at one point kubernetes was deployed within Docker Enterprise as you create a swarm cluster and then deploy kubernetes on top of swarm. >>Correct? That is how the current architecture works. >>Okay. All right. And then, um what is what is where we're going with this like, Are we supposed to? Are we going to running Swarm on top of kubernetes? What's >>the the design goals for the future of swarm within branches? Stocker Enterprise are that we will start the employing Ah, like kubernetes cluster features as the base and a swarm kit on top of kubernetes. So it is like you mentioned just a reversal of the roles. I think we're finding that, um, the ability to extend kubernetes a p I to manage resource is is valuable at an infrastructure and platform level in a way that we can't do with swarm. We still want to be able to run swarm workloads. So we're going to keep the swarm kit code the swarm kit orchestration features to run swarm services as a part of the platform to keep the >>got it. Okay, so, uh, if I'm a developer and I want to run swarm, but my company's running kubernetes what? What are my one of my options there? Well, I think >>eight touched on it pretty well already where you know, it depends on your design goals, and you know, one of the other things that's come up a few times is Thea. The level of entry for for swarm is much, much simpler than kubernetes. So I mean, it's it's kind of hard to introduce anything new. So I mean, a company, a company that's got most of their stuff in kubernetes and production is gonna have a hard time maybe looking at a swarm. I mean, this is gonna be, you know, higher, higher up, not the boots on the ground. But, um, you know, the the upper management, that's at some point, you have to pay for all their support, all of it. What we did in our approach. Because there was one team already using kubernetes. We went ahead and stood up a small cluster ah, small swarm cluster and taught the developers how to use it and how to deploy code to it. And they loved it. They thought it was super simple. A time went on, the other teams took notice and saw how fast these guys were getting getting code deployed, getting services up, getting things usable, and they would look over at what the innovation team was doing and say, Hey, I I want to do that to, uh, you know, so there's there's a bunch of different approaches. That's the approach we took and it worked out very well. It looks like you wanted to say something too. >>Yeah, I think that if you if you're if you're having to make this kind of decision, there isn't There isn't a wrong choice. Ah, it's never a swarm of its role and your organization, right? Right. If you're if you're an individual and you're using docker on your workstation on your laptop but your organization wants to standardize on kubernetes there, there are still some two rules that Mike over Ah, pose. And he's manifest if you need to deploy. Coop resource is, um if you are running Docker Enterprise Swarm kit code will still be there. And you can run swarm services as regular swarm workloads on that component. So I I don't want to I don't want people to think that they're going to be like, locked into one or the other orchestration system. Ah, there the way we want to enable developer choice so that however the developer wants to do their work, they can get it done. Um Docker desktop. Ah, ships with that kubernetes distribution bundled in it. So if you're using a Mac or Windows and that's your development, uh, system, you can run docker debt, turn on your mode and run the kubernetes bits. So you have the choices. You have the tools to deploy to either system. >>And that's one of the things that we were super excited about when they introduced Q. Burnett ease into the Docker Enterprise offering. So we were able to run both, so we didn't have to have that. I don't want to call it a battle or argument, but we didn't have to make anybody choose one or the other. We, you know, we gave them both options just by having Docker enterprise so >>excellent. So speaking of having both options, let's just say for developers who need to make a decision while should I go swarm, or should I go kubernetes when it sort of some of the things that they should think about? >>So I think that certain certain elements of, um, certain elements of containers are going to be agnostic right now. So the the the designing a docker file and building a container image, you're going to need to know that skill for either system that you choose to operate on. Ah, the swarm value. Some of the storm advantage comes in that you don't have to know anything beyond that. So you don't have to learn a whole new A p I a whole new domain specific language using Gamel to define your deployment. Um, chances are that if you've been using docker for any length of time, you probably have a whole stack of composed files that are related to things that you've worked on. And, um, again, the barrier to entry to getting those running on swarm is very low. You just turn it on docker stack, deploy, and you're good to go. So I think that if you're trying to make that choice, if you I have a use case that doesn't require you to manage new resource is if you don't need the Extensible researchers part, Ah, swarm is a great great, great viable option. >>Absolutely. Yeah, the the recommendation I've always made to people that are just getting started is start with swarm and then move into kubernetes and going through the the two of them, you're gonna figure out what fits your design principles. What fits your goals. Which one? You know which ones gonna work best for you. And there's no harm in choosing one or the other using both each one of you know, very tailor fit for very various types of use cases. And like I said, kubernetes is great at some things, but for a lot of other stuff, I still want to use swarm and vice versa. So >>on my home lab, for all my personal like services that I run in my, uh, my home network, I used storm, um, for things that I might deploy onto, you know, a bit this environment, a lot of the ones that I'm using right now are mainly tailored for kubernetes eso. I think especially some of the tools that are out there in the open source community as well as in docker Enterprise helped to bridge that gap like there's a translator that can take your compose file, turn it into kubernetes. Yeah, Mel's, um, if if you're trying to decide, like on the business side, should we standardize on former kubernetes? I think like your what? What functionality are you looking at? Out of getting out of your system? If you need things like tight integration into a ah infrastructure vendor such as AWS Azure or VM ware that might have, like plug ins for kubernetes. You're now you're getting into that area where you're managing Resource is of the infrastructure with your orchestration. AP I with kube so things like persistent volumes can talk to your storage device and carve off chunks of storage and assign those two pods if you don't have that need or that use case. Um, you know, KUBERNETES is bringing in a lot of these features that you maybe you're just not taking advantage of. Um, similarly, if you want to take advantage of things like auto scaling to scale horizontally, let's say you have a message queue system and then a number of workers, and you want to start scaling up on your workers. When your CPU hits a certain a metric. That is something that Kubernetes has built right into it. And so, if you want that, I would probably suggest that you look at kubernetes if you don't need that, or if you want to write some of that tooling yourself. Swarm doesn't have an object built into it that will do automatic horizontal scaling based on some kind of metric. So I always consider this decision as a what features are the most I available to you and your business that you need to Yep. >>All right. Excellent. Well, and, ah, fortunately, of course, they're both available on Docker Enterprise. So aren't we lucky? All right, so I am going to wrap this up. I want to thank Don Bauer Docker captain, for coming here and spending some time with us and eight of Manzini. I would like to thank you. I know that the the, uh, circumstances are less than ideal here for your recording today, but we appreciate you joining us. Um and ah, both of you. Thank you very much. And I want to invite all of you. First of all, thank you for joining us. We know your time is valuable and I want to invite you all Teoh to take a look at Docker Enterprise. Ah, follow the link that's on your screen and we'll see you in the next session. Thank you all so much. Thank you. >>Thank you, Nick.