Thank you very much. All right, so we're going to do this sort of, I guess, stand up comedy because I have a handheld microphone right now. So who am I? As was mentioned, I'm a technology evangelist at Docker, so I work for Docker Incorporated, which is the company behind the Docker project. I spent the first half of my career doing IT networking and SysAdmin stuff, but that was a long time ago. So I was a certified Banyan engineer. There's always like one or two people that are like, wow, that's old. And then I was a Microsoft Certified Systems Engineer on Windows NT 3.1, so that's how long ago that was. So then I moved in, second half of my career, I've been doing a lot of product management and technical marketing for Docker. Most recently, before that, I was at Puppet Labs. So that was sort of my open source exposure, coming into Puppet Labs. Before that, I spent about six years at VMware, sort of from 98 to right, 2008, 2015. And then before that, I spent six years at Microsoft, where I did a bunch of stuff on IT admin features and functionality for versions of Windows, starting with Windows 2000 or NT5, whatever it was called. If you've ever installed Windows XP and you've ever read the text that says, Windows XP will be faster and more reliable, I wrote that text. So that's my claim. Well, my other claim to play with Microsoft is I was on stage with Bill Gates in an earthquake. So there's that, too. I come from an IT pro background. I'm not a developer. When I pretend to be a developer, you'll see painfully, obviously, how I am not a developer. But if we get to a demo, then we'll see that. You can follow me on Twitter. I tweet mostly about soccer and the Portland Timbers, occasionally about work. So why are we sitting here today? So first, I'm going to start with the informal poll question. We'll start at the high end and move down to the more beginner end. How many of you are deploying containers in production today in your company or in your organization? That's actually really good. Normally, I just did Container World, and I had a room of about 100 people, and I had six people in production. How many of you have downloaded Docker and have done a POC with it? So you're planning to go to production. How many of you have downloaded Docker and run something like a Hello World app or a demo app? How many of you are brand new to containers and are here because you just want to learn? It seems like everybody, the same people, all raised their hands. It looked like it was about 25, 25, 25. So we're going to spend some time on what is Docker to get people up to speed. So if you're familiar with it, bear with me. We'll get into a little bit deeper stuff. But as you get familiar with containers, as you start moving into that journey, questions come up, right? Especially if you come from how many of you are developers? How many of you are sysadmins? So this talk is really aimed at people coming from the sysadmin perspective. What are these things I need to know about? So when do I use a container? When do I use a virtual machine? If I'm going to deploy containers, do I put them on a physical box or a virtual box? Do they go in the cloud? Do they go in the data center? All of those different things. So we're going to talk a little bit about how you answer those questions. Actually, I'm going to give you the questions to ask, to answer the questions you wish that I would answer for you, because I can't answer your questions. And you'll understand why as I go through the presentation. So we're going to talk about what are containers and what containers are not. Containers are not virtual machines. When I first started at Docker, the summer of 2015, everybody would be like, oh, it's like we're virtualization. Oh, I've heard Docker. It's like we're virtualization. They're lightweight VMs. They're not VMs. They're totally different. They have different architecture. They have different benefits. So if you think about a virtual machine, a virtual machine is a house, right? It's fully self-contained. It has its own heating, its own plumbing, its own air conditioning. It has a front door, so you can't just bust into it, right? It's got a little bit of security there, a little isolation. Think about a virtual machine. It's a self-contained operating system. The entire OS is in there, right? And if I'm running, let's say I'm running a couple of servers and their web servers, and I need to have a third for capacity, I spin up a virtual machine. I spin up a whole new operating system. I build a whole new house. There's nothing shared between those houses, right? I would say maybe the sewer, and that'd be the network, but that might offend the network guys, so I won't say that. So VMs, monolithic, fully self-contained. If you need more capacity, you expand them out, right? Houses can be different. They can kind of look different, right? Like you can have one house that's kind of a big two story house, next to a one story house, and they're different sizes. But houses only get so small. First house I ever bought was about 800 square feet. It was two bedrooms, a bathroom, a living area, and a kitchen, right? That's the smallest houses I could find when you talk about proper houses. I could talk about micro houses, but they break my analogy, and some of them are made out of containers, and they really break my analogy. So we'll stick on normal houses. And that's like VMs, right? Even if you go and you shrink them down, you're usually looking at a couple hundred megabytes to get in a VM, right? And sometimes you're talking 10, 20, 30, 40 gigabytes, right? They get really big. So containers, how are they different? So think about containers as apartments inside of an apartment building. So an apartment building is the Docker host. The Docker host is any computer, physical or virtual, cloud, data center, whatever, that runs the Docker engine. The Docker engine, you know what I'm talking about? There's a lot of different container runtimes. I'm going to talk about Docker, right? This whole idea of container runtimes, pretty much this is exactly the same in all of them, right? So you've got a system running the Docker engine or container runtime. And that's like the doorman at the apartment. Now what makes an apartment different than a house? Well, one of the fundamental things is it shares the infrastructure. It shares the heating, the plumbing, the air conditioning, right? It shares the elevator. Containers are processes inside an operating system. They share the underlying kernel in the operating system, right? So unlike a virtual machine which has its own kernel, containers share that resource. That means there's a couple of big benefits. It means there's also a couple of limitations with respect to virtual machines. The big limitation is that every container running on that host has to be from that host family, right? So you cannot run a Windows container on a Linux host. You cannot run a Linux container on a Windows host, right? Because they share the kernel. But you can have a host that's running CentOS and you can run an Alpine Linux container on it, or a Red Hat Linux container on it, or a Ubuntu Linux container on it, right? As long as the architectures are the same of the underlying hardware, those things are just going to move along. But like houses, we have a front door, right? So a container is isolated, can't just bust into it. And then the containers can be quite small. Someone, they're doing a kind of informal, if you want to get on a little informal competition on Twitter, one of the docker, I don't know if he's a captain or not, but he's an aficionado at least, a community member, hacker, pose the question, what's the smallest hello world container you can write? So what's the smallest container you can write that says hello docker, right? And so anybody want to guess what the size is, the smallest I've seen? 68 bytes for that container. So that's a full running container, 68 bytes. I have an Alpine Linux container that's 2.6 megabytes, that's a full operating system, right? And so containers are much, much smaller than virtual machines. The other thing, or they can be, right? The other thing is that in a container, because it's booting up a process, it's not booting up an operating system, they start really fast. They start in about three-eighths of a second compared to a virtual machine taking several minutes to boot. So fundamental differences, shared resources versus dedicated resources, a little bit faster, a little bit smaller, but sort of very homogeneous in the network, or excuse me, in the, with respect to the operating systems you run. But just because they're different doesn't mean they're mutually exclusive, right? What you see is most people, you see what's on the, my left, your right there, where people are taking containers and they're running them inside of virtual machines, right? They go and they spin up a Linux VM or a Windows VM. How many of you knew that there was containers on Windows now? A handful of you. OK, I don't have that in my slides. I know this is the Linux Expo, but how many of you run environments that are 100% Linux with no Windows at all in them? So like 20%, like, you know. So for the rest of you, containers are also available on Windows Server 2016. I won't get into it in a lot of depth, but just know that there are such a thing as Windows containers. They use the exact same API, the exact same CLI as the Linux containers do, right? But they're based on Windows operating systems, not Linux operating systems. So you could, in this example here, one of these blocks could be a Windows Server 2016 machine with Windows containers. The other could be a Linux virtual machine with Linux containers. And you could just have a traditional VM over there doing whatever. Or you can run them on bare metal. You can have a host OS running on a piece of hardware. And you can install the Docker engine. The thing is, it doesn't matter, right? If these are Linux containers, they can move from the left to the right seamlessly, regardless of the distribution underneath, right? So in tests I'm running, sent to us in production, I'm running Red Hat, whatever. It doesn't matter. We can move across there. So like I said, there's really good reasons for each of these architectures. And I'll get into them in future slides. So one thing I want to talk about today with regards to the Docker project, we just announced this today. So I have this in here. And so this might be of interest to everybody. So today we announced we're actually releasing two versions. So we're splitting the project, not splitting the project, but we're splitting it up into two specific releases, right? So Docker is a commercial company, right? I work for a software company called Docker that happens to manage the open source project Docker. And we wanted to make sure people understood that there were a couple of different ways to get Docker. So the first is Enterprise Edition. And I won't spend a lot of time talking about this because it's a commercial offering. It's stuff that we sell. But basically, it takes the Docker technologies. It bundles them up into releases for people who want support and they want some advanced features. Then we have Community Edition, which is the same Docker that people have been using forever under open source, right? So it's great for do-it-yourself organizations or hobbyists or all that kind of folks. We're going to be on a quarterly release with those. With every month, you'll get an edge, what's called an edge release, right? So it used to be experimental or beta. You're going to be able to see, OK, I'm on 17.3 edge, right? And that's the sort of beta upcoming releases. And then we do maintenance and support on the Community Edition for four months for each version. We do it for a year on the Enterprise Edition. Enterprise Edition also comes with a whole bunch of certified certification stuff.  So this is new, and you're going to hear more about it, but I just wanted to bring it up since we were here this morning. We're also going to talk a little bit about editions, right? And I'll talk about editions at the end, but I wanted to explain what an edition is. An edition is any way you get Docker running on your machine. So I have a whole Getting Started section, but we release Docker for Windows, Docker for Mac, Docker for Azure, Docker for AWS, right? And those are ways for you to get up and running and integrate with whatever platform you're running on. So when you think of something like Amazon, it's going to take into account load balancers, it's going to take into account S3 storage, it's going to take into account the VPCs and the Natting and everything you need to run, right? It'll stand up Docker, build all that infrastructure out for you. That's something you can get with Community Edition, thoroughly free if you're running on AWS, it's the fastest way to get up and running. We'll talk about that a little bit more later. Skip this slide. So the idea basically is with the Docker platform, regardless of whether you want to pay for your software or not, we're going to give you one platform, right? And the idea here is that the promise of Docker and at the end of the day, why people deploy it is that they want to be able to write an application, have their developer write an application on their workstation and have that seamlessly flow through the environment and move from developers to a QA into production, right? And they want to be able to do that on Linux and they want to be able to do that on Windows and they want to do it on premise and they want to do it in the cloud, right? And any type of app, when I joined Docker, everybody was like, oh yeah, it's containers, it's only for microservices. And what we're seeing is most of our customers today are not exclusively using Docker for microservices and I'll give an example later, companies are taking traditional applications out of VMs, containerizing them and putting them on to Docker for a number of different reasons which we'll go through. So if you've got homegrown applications, ISV applications, microservices, it doesn't matter, right? All of that, moving that. And if you're on Community Edition today and you want to move to Enterprise Edition, great, it'll just work. Okay, so now that I've been speaking for like 15 minutes, some of you were in there like just answer the question. Like the question I came here to get answered. But the thing is like one does not simply answer the question without doing a bunch of marketing stuff. Besides, you wouldn't like the answer, right? So this picture, so when I was at VMware, I would get this question and actually who thinks, what, I want to hear what you guys would say. What is the number one question I answered when I was at VMware? Yeah, well that was number two, but, because I didn't actually, people asked me like how much it costs, I'd be like, I have no idea, I don't sell software. Okay, so the number one question I got was how many VMs can I run on my server? What's the answer? It depends. But if I was feeling kind of nice, I would say it depends. If I was feeling surly, I would say, how many plants can I get in my car, right? Because it depends on your car. It depends on the plant, right? So my car is a, I used to have a suburban, it was a better analogy when I talked about, when I had my suburban and my wife has a Honda Fit, right? All right, so I could clearly carry more plants than her, well no, because I'm carrying ficus trees and she's carrying pansies, right? So it's, there isn't an easy answer to this, right? There's a lot of variables to consider. So when you think about, and you say, okay, well I get, I understand what a container is, but I still don't know what I'm gonna do with it. There's all these things you have to think about. So I went back and I, and we go back a couple of slides, and I talked about this idea of, you know, mixing and matching your workloads. This is all about capacity planning and, you know, somewhat about licensing, licensing costs, but if you think about where VMware came from, like, so 2008, VMware was really picking up steam and the number one use case was, I stand here all day. Legacy I'm sure, but the problem we were trying to solve was resource utilization, right?  So then we said we put the database and the exchange server and the IIS server into VMs and we can now put them on one VM, on one physical server and I now have a machine running at 80% utilization instead of 30% utilization. So I'm spending a lot less money on hardware. That's where we came from. If you're sitting there today on your first stages of your container journey and you don't have enough capacity to drive the server utilization, you'd be foolish, you know, if your number one concern was capacity utilization to put that on bare metal, right? Because you would be wasting money on that hardware. So capacity planning and mixing workloads. But now if you go, wait a minute though, I have a security implication and there are security implications that say I cannot run this workload on a shared kernel. Like there's some, you know, there's a law or there's a security policy or there's a regulation or something. Then you're like, well, what do I do? Well, I put it in a VM then, right? Because I have to because in a lot of play, a lot of people still consider, well, I mean, it is a shared kernel technology, right? And so they are like, we can't do that. It's just a policy, we can't do it. So if you have multi-tenancy requirements, right? And especially in the Linux space, in the Windows space, there's this thing called a Windows container with Hyper-V isolation, which we're not gonna get into, but if you're interested in that, find me afterwards and I can tell you about it.  But wait a minute, I really care about performance and latency.  They run faster than virtual machines. They run faster than containers in virtual machines. They are fastest on bare metal. So you're sitting there and you work for a financial trader in New York City, a company who just paid $70 million to relocate their data center two miles closer to reduce their latency by three milliseconds because they do that kind of thing when you're dealing with billions of dollars in trades.  So there's that. So anyway, if you think about it, there's a lot of different variables in there. The only one I haven't really touched on is, and some of you were sitting out there and you're like, well, I'm a vSphere admin, right? All my tooling is vSphere, all my tooling is KVM, all my tooling is Hyper-V, all my tooling is Puppet, all my tooling is Chef, all my tooling is Ansible, right? So you've got these existing automation frameworks and you've got these existing skill sets. So you look at that and you say, well, it just doesn't make sense for me to go 100% into containers right now. Like I wanna keep what I've done with vRealize automation or vCake or whatever it is, right? So that's another thing where you look at it and you say, how am I gonna make this transition with my skill set and my staff and the people who have to do the work? Because a lot of people come in, especially on this admin side, they come into containers because someone walked into their office one day and said, hey, the new app is ready, it's in a container, go ahead and put it in production. And you're left with this slide and you're left with, well, I don't know how to capacity plan for that. I don't know how to secure that. I don't know how to do that. So we're gonna take a look at two examples and we're gonna talk about first consolidation and compute consolidation and then we'll talk a little bit about security. So VM consolidation, so this slide is actually based on some testing we did with Hewlett Packard. So HP and then we had an independent consultant named Brett Fisher went out and they took suspension, they ran suspension. What they did is they took suspension, they said, okay, on this physical server, we're gonna create eight virtual machines and we're going to run suspension them and then we're gonna measure the output. So let's just say for Grins that each machine or each VM could do 1,000 transactions per second, so 8,000 total transactions, right? So then they said, well, what happens if we put that in containers?  So they took the eight VMs that were using 16 cores and 16 VCPUs and 32 gigs of RAM and they made one big VM that was 16 VCPUs and 32 gigs of RAM. Just again, kind of just making up these details really, kind of making this whole thing up. Actually, that's not true. This is actually a true study. And what they found was if you move, just by moving from eight smaller VMs into a single VM, you actually got 27% greater output. So where you were running and getting 8,000 transactions total per second, you were now getting 10,000 transactions per second, which means if you had a server farm out there, you could take 25% of the servers out of the farm and still do the same amount of work by moving from a bunch of smaller VMs into a larger VM and containerizing those workloads. So if you had each container represented a different work group or some other different workload, by bringing those together, the other thing that you've done there is you're gonna use about 30% less storage. You're gonna use about 7% less RAM. You were going to move from managing eight guest operating systems in eight virtual machines to a single guest operating system in a single machine. And you're gonna reduce your data center footprint, right? So less electricity, less cooling, less real estate. I will say so for those of you in the room wanting the technical details on this, one of the things we did have to do was it wasn't a straight just move over. We did some stuff with pinning and affinity to make sure that the workloads went to the right CPUs. And there is a 50-page white paper on this available from Humboldt Packard. So if you follow me on Twitter, I will tweet the link out to that paper after this talk. And it goes into all the detail of how we did it, right?  So if you do that exact same experiment and you go, okay, now I'm gonna take eight VMs and I'm gonna move into eight containers running on bare metal. So no virtualization at all, you get a 47% output increase. So you go from doing 8,000 transactions per second to about 12,000 transactions per second. Again, I'm just using those numbers to make them easy to, you know, because they're even whole numbers. But what it basically means is if you were doing a server farm, you could take two of those servers out, right? It's a little trickier than, it's a little trickier if you say, well, I have one server doing the work because of the affinity and the pinning. So that sort of example works better when you talk about using server farms. But if you were just on a single server, you would still get more output from that box than you were before. So again, storage savings, operating system management savings. You go from managing eight guest OSes and eight virtual machines to running a single host OS running on bare metal, right? So you have the bare metal server, your Linux operating system and the Docker engine and eight containers out there running. So that is, you know, the VM to bare metal consolidation. So things to think about then. So you're like, all right, so that's interesting. So what do you gotta do, right? Like, so higher density. Like, containers are going to give you higher density than you're used to having. So just think about that, right? They, because they're lightweight processes, you know, you're going to just get more of them in there. They're gonna be more responsive. Bare metal or bigger VMs, right? So do you want to now look at getting rid of virtualization all together in some use cases? Well, if you don't have to worry about multi-tenancy, right? That's a, you know, if your existing tool set lets you do that, right? Then you can get performance gains there. So you can, you have to balance those things out. And then tuning to optimize. So I mentioned this before, right? We didn't just slam those VMs and just move them over, right? We had to do some work with the affinity and the pending on the CPUs. The white paper details exactly what we did. But by, you know, by tuning it a little bit, right? And it took the consultant, you know, a couple of days to figure that out, right? He made an investment about, you know, I think most of us would invest 16 hours to get 47% performance gains. That's a pretty big return on your investment there. So that is, you know, the idea of like capacity planning and some real quick overview on that. But that's an indication of the things you need to start thinking about. We're not, you know, you don't want to just go into it on this mindset of, oh, they're exactly the same. We can just sort of do this one to one mapping because there are things are going to change for you. So what about security, right? I put this in here because that probably the number one, well, it's not really the number one, but one of the top five questions I get about Docker containers is what about security, right? Most people, when they say Docker container security, they worry about like exploits that allow you to break out of the container, which have happened. They've been there. We work very hard to protect against those as do all the members of the community. But security is more than that, right? When we look at security, we think about end to end security and how you can do that. And we look at it now from this perspective of, like there's three things that we really care about with security. The first is that it's usable because if you make security unusable, if you make it hard, they're going to circumvent it, they're going to write that 15 character password on a post-it note and they're going to slap it on the side of their monitor. They're going to use the same password for every system. Like I'm guilty of that. I'm not guilty of that. Do not try to hack me. Anyway, so we know this, this is a common edict, right? And you want to have a way to move things around in a secure manner, right? It's not just about like what's happening when the container is running, but what happens to that application through the entire life cycle? How do I guarantee that the application that I'm putting in production is what I think it is? How do you know when you deploy a VM that it's actually the VM you think it is? How do you know that somebody didn't come in and swap that VM out? And you're looking at it and it says, Master Golden Image 216, 216, 2017.7. And you think you've got the right version. How do you know that I didn't come in last night and change that and just rename it? You don't, I don't think, maybe you do. And then whatever you do with that container, whatever you do to define that security policy, it needs to follow that container regardless of where that container exists. Infrastructure independence, right? So my security works on my MacBook, my security works in the cloud, it works on my data center, right? All of that equals safer apps. So how do we, how do we do that, right? So things to think about when you're looking at deploying containers in production around security. One is application secrets. How many of you pass, okay, we're gonna do it like they used to do in Sunday school. Everybody close your eyes so nobody has to be embarrassed. How many of you pass passwords using environment variables or in static config files? Come on, all right, there's a few brave souls. I think more people than raise their hand do it, right? We all know that there's an inherent risk in that, right? So how do you pass that stuff securely? How do you maintain a workflow that works for your developers and your operations team? And then how do you set up a system that out of the box is already secure? So we're gonna talk about those things in a little more detail. I think, hold on, we're gonna talk a lot about secrets. So in here, the image signing and image scanning and verification. So these are functions available through Docker. Image signing and verification is fully open source. It uses something called Notary, which is based on the update framework. The image scanning is actually a paid service that you can have added to your private repos on Docker Hub or you can have it added to your Docker data center enterprise edition thing. But what they do is they work in concert. So the idea is with image signing, I as a operations person provide a base image to you. So you're going to write a Java application. So I hand you a Java app, a Java image and I've signed it digitally. So as a developer, as an operations person, you can configure Docker to only run signed images. So I'm a developer, I pull down the Java image and I try to run it. Docker verifies the signature that runs. I add my code, I sign it. So now it's been signed that it has the right base image. It's been signed that the application you're about to deploy has come from one of your developers, right? And then it goes to QA, right? And it goes through the testing process or whatever and then the CICD system or whoever signs it. Before I can put it in production, I can verify that it's been signed based on a secure base image, that my developer wrote it and then it's been through our testing cycles. And that's what we mean by the secure software supply chain, right? That's the marketing term for it, as we move through each step in the process, we can verify that it's been working, right? So the other thing is image scanning. So again, this is a commercial thing, but just for completeness of the story. Once that container is running, we can do a, when containers get stored on something called a registry, right? It's a server to store your Docker images, your container images. When you push an image, when you send it up to the registry, when it hits the registry, we can scan it. We do a bit level scan on it. We can break it down. We know everything running in that image and we can list all the vulnerabilities out for you. So we can say, look, this image has these known vulnerabilities based on this CVE database and the CVE databases will be updated regularly and will rescan for you. So once you put a container in production, we will tell you if anything is ever discovered against that container so that you can go out and then remediate it, right? It's this ongoing security vulnerability scanning. Couple of other things, we talked about secure by default. The idea of full TLS encryption across all the communication between the containers or the host in the system and that all information is passed over secure channel by default. And then as you deploy in production and you start getting into a little bit of the, some of the, again, a commercial feature, users and role-based access control, right? So syncing with Active Directory and LDAP for user information and then using that to apply granular permission so that when you put a container in production, if it's a production version of the container, only the ops team can modify it, right? The development team can see it or maybe they can't, right? But they can't modify it or any level of permissions in there based on these labels that you apply. So being able to go through and ensure that only the people who should have access to those containers do it and regardless of where it's running, right? Regardless of the system that it's on, we should be able to do that. So we already know what this is. I wanna make sure there's anything. I didn't really talk about the secrets, but let me, I'm gonna use this slide because I wanna get done here in the next 10 or 15 minutes. So a couple of things on secrets management. This is actually new in the latest release of Docker. So what we basically do is we use Docker swarm mode. So we're gonna come up next, we're gonna talk about Kubernetes. Kubernetes is a clustering and orchestration system. Docker has one called swarm mode and in the cluster managers, right?  In those managers, we store, we can store the secrets. Now they're encrypted by default at rest in the store, right? And so, and they're encrypted while they're sent across the network. And those secrets will only be sent to systems that actually are running containers that need them. So if you've got 10 servers and only two of them are running the database, we're only gonna send the secrets of those two machines. They are never stored on the disk on those worker nodes. They're mounted in an in-memory file system. So you don't have to shred the disks when those machines go away because nothing was ever written to them in that regard. And the other thing we have is we have something called cryptographic node identity. So those worker nodes can't be spoofed. You cannot go into and say, oh, I'm worker seven because worker seven was cryptographically signed by the manager. And so we can verify that identity, right? So there's a lot of protection built into that. So if you kind of look at this right here, right? So the RAF consensus group is all those managers. That's the data store. We put the secrets up there and you can see in the example below we have three workers but the secrets are only put down under workers one and three because that's where the containers are running, right? Every, all the communication between those workers and the managers is encrypted. So that's what we, when you think about security, don't just say, think about, oh, did I patch this or did I, did I, you know, is the container isolated? Think about the entire end-to-end story. Think about protecting stuff in ways you actually maybe hadn't thought about before. Being able to adopt different ways of managing sensitive information. So we talk about passwords here but you can send anything through a secret, right? You can send directory environment variables, directory structures, whatever you wanna send, like any piece of information. All right, so why do we even start, right? So why do we even start? And I kinda, sometimes I start with this and sometimes I end with it because I think it's hard to understand it if you don't kinda have a little bit more information about what containers do. So we start by, you know, just being faster, just being quicker, right? Being able to run CI CD pipelines on containers and you can cut the time to do a test cycle by orders of magnitude simply because if you're booting up 100 VMs to do scaling testing, that's going to take you a couple hours potentially and I can boot 100 VMs or 100 containers in 15 seconds. So I go from hours to seconds to get my infrastructure and if you think again like CI CD, I'm not managing a Java build server and a Python build server and a whatever build server. I have build servers and they run Docker, right? Or they run some container runtime and everything comes into the container because everything my application needs to run is in the container. I don't have to do anything with it, right? That makes all the dependencies much simpler, right? The dependency to now run your application on the infrastructure side is an operating system and the Docker engine, right? You don't ever have to worry about what version of Java is installed on that machine or I'm a Java developer and you wanna send me Python, I have to install Python, I don't have to worry about any of that anymore. Unified tool chain, yep, unified tool chain. So the idea that the CLI and the API that you use is the same on your MacBook where you're using for development. It's the same as on your Linux hosts running up in Azure. It's the same as the hosts running on vSphere. It's the same APIs and the same CLIs. Oh, and by the way, it's the same APIs and CLIs from Linux to Windows, right? So Docker run is Docker run wherever you type it. Docker pushes Docker push wherever you type it. We talked about that API automation. I'm going to move forward to... Actually, I wanna talk about this stuff. So you're like, okay, cool, I don't know where to start. I heard that I have to do microservices. The reality is that you can do any number of different application paths into Docker, into containers, right? So we talked about already the benefits of just lifting and shifting applications. Just taking an application and moving it into a container is going to be more performant. Even if you keep it in the VM, you're going to get better performance that way, right? You're going to get better portability. And a lot of people are doing that. We have customers who, we just did an announcement with a big financial company back in New York, like a Fortune 5 company, Fortune 40, sorry, that's doing lift and shift on Windows. And they're moving a bunch of their applications into Docker containers, just straight up moving them in there. And sometimes what people do is they move them into containers and they start breaking them down, right? So they take a container and they take an application and they say, all right, I'm moving that into a container. Well, now I've got these three applications that are all running in containers. And I notice they all have the same authorization, sort of authorization function. I'm going to put that in a microservice and I'm going to point those applications out of the VM into the microservice and they start breaking those things down, right? There's this whole continuum between monoliths and a monolith being a traditional standalone application and microservices and you can be anywhere on that journey.  The things you have to worry about with containers as you start looking at these monolithic applications are things like fixed ports and static configs, right? When you have to define the application for different environments and you're talking about a container where everything is sort of the same, that can be problematic. But the beauty is, and this is my favorite, absolute favorite thing about Docker. And this is, this could be my last question I ask you guys. How many of you have ever deployed an extremely complex project exactly 100% correct the first time? Oh, I saw a guy trying to raise his hand over there. You guys get his number quick, hire him. You guys want that perfection, right? No, and that's the thing about Docker is that, you know, we hear a lot of people that are like, oh, you know, we were in the cloud and we realized the economics of the cloud didn't work. And so now we want to move back to the data center. Super example, you know, common example, super easy to grasp. The problem is that if you've done that and they're in EC2 instances and they need to end up over here in a virtual machine, how do you do that? Like that is a serious engineering effort. If they're in Docker containers, it's trivial, right? And what I mean by start somewhere and end somewhere else is you are able to recover from decisions that you've later come to realize we're not the right one. I don't want to call them mistakes because we don't make mistakes. Well, at least, I thought I was wrong once, but I was mistaken.  Well, it's easy to recover from that and adjust to it and move around on the fly. I'm gonna skip that. So getting started, for those of you who are new to Docker and don't have it, if you have your Linux machine, you can just do curl, SSL, HTTPS, getdocker.com, pipe that to shell and you'll have Docker in about three minutes. Now, for those of you who do not want to pipe to shell, we have full manual installation instructions up on our documentation. If you want to do beta builds, you could do test.docker.com. If you want to do bleeding edge, you could do experimental.docker.com. Any of those will get you up and running. All you need on the Linux side is a kernel greater than 3.1. That's the requirement, right? A kernel greater than 3.1. We've got a whole bunch of, any Raspberry Pi enthusiasts in here? Anybody got Docker running on the Raspberry Pi yet? There's a company out there called Hyper, I call them Hyper, I don't know how they say their name, but they're basically, they're all about Docker on Raspberry Pi. They're actually doing a DockerCon workshop on getting Docker running on Raspberry Pi at DockerCon this year. But if you, that's something you can geek out on. So even on Raspberry Pi, if you are running Windows or Mac, you want to get Docker for Mac, Docker for Windows, easy to download. It uses the integrated virtualization on the platform. It is running to be able to get Docker up and going in a matter of minutes. So I'm running on Docker for Mac. On Windows it uses Hyper-V, on Mac it uses Xhive, super fast. Again, the same API, the same CLI, it doesn't matter. It's going to work exactly the same way. We used to have something called Docker Toolbox. How many of you have used Docker Toolbox? How many of you love VirtualBox? Some people liked VirtualBox. We moved away from it because there were some limitations on it. And that's what we mean by OS integration for speed and stability. So if you're in the cloud, right? If you're using Azure or AWS, we actually have the ability to go out and run a cloud formation template or the Azure equivalent, an ARM template, I think is where they are. And you can basically stand up a Docker cluster in about, well, you can kick it off in 30 seconds. You actually answer like five questions and it will build you a full Docker cluster up in AWS. It'll integrate with the load balancers and everything. So if you start a service on the cluster that needs a firewall port opened, it will open the port for you, like that sort of integration. And I was geeking around the other day and I just said, like, what could I do with this? And I deployed a thousand node cluster up in AWS. Like I just said, give me a thousand nodes. And like it took an hour to provision all the instances, but they all came up and I had a thousand node cluster up and running. So that's pretty nice. We do that for Azure and AWS. So, RockJog run. So you're new to Docker, go out and install Docker for Mac, Docker for Windows, put it on your Linux box and just do Docker run hello-dash world, right? Super easy, you could run Mike G. Coleman Catweb and you could get a really cool website that shows random catgifs in a Docker container. And then so for me, when I came to Docker, I knew nothing about containers. So I went on and I said, what are the things that I could do?  So I went and found Jenkins and I got a Jenkins container and I built a Jenkins CI CD pipeline with Docker that basically runs the test jobs, pulls the Docker file off a GitHub, builds the container, tests the container, if the container is good, if the test pass, pushes it back up to Docker Hub, right? Do something like that or WordPress because WordPress has multiple components, right? Build something like that. There's a thousand and one blogs on all these things. Go check those out. And then once you get that done, you can say, well WordPress is cool, but I need multiple databases on the back end. How do I do a replicated database or a sharded database or a scaled database? Or that Jenkins thing was cool, but I really want a full CI pipeline, right? I want more than just getting it to Docker Hub. How do I build this so that it pushes it into production? And what does that look like? Build your own Docker files. We didn't talk about that. Build your own compose files. Get into swarm mode. Talked a little bit about swarm mode. Didn't talk much about compose. These are some of the more advanced features of Docker you can play with, right? So at the end of the day, I'm not here. So I made the comment. I'm here to get you the questions that you need to answer to answer the question that you wish I would answer for you. I can't answer it for you. I can't tell you how to run your application in a container because only you should understand at the level necessary to make that informed decision. I will say that putting something in a container does not abdicate you of the responsibility of understanding how your application works and what it does. You still need to understand your applications. You still need to performance profile them, all those sort of things. And then pick the right tool for the job. Containers are not a panacea. They are not the right tool for every job. I think there's a lot of problems they solve and I think they're obviously the motion and stuff that we're getting shows that a lot of people are happy with them. But it's up to you to decide what the right tool for the job is.  So what's next? Go ahead and pick a project. Get your hands dirty. You will make mistakes. You will do things like inadvertently delete every image on your system or corrupt an entire cluster and have to rebuild it from scratch at 11 o'clock on a Thursday. At least I did. But join the community. So if you're not involved in the Docker community, we have thousands of contributors. We have a bunch of ways for you to get involved, everything from just downloading it, playing with it and opening issues and letting us know what doesn't work to joining a meetup. Like I was mentioning, I'm the organizer, one of the organizers for the Portland Meetup. Join our community. Share what you've learned. And with that, I have about three or four minutes for questions before we need to bring up the next slide. So thank you very much. And if you have a question, let me know and we will do our best. I don't know if we have another microphone or if I should just run around. I think I have to run around. Okay, any questions? Perfect presentation. No questions. No, this guy's got a question, he's gonna ruin it. I was born 300. So the gentleman's question was, we talked about Docker for Azure, Docker for AWS. Is there Docker for Google Cloud? I'm not sure that I can tell you that we're working on that. But I think I can. And I think, so what we did with, what we did had the way that Azure and AWS came out is we did a private beta where you would send in a request and we would approve you and let you in. Then we did a public beta. I'm not sure where we're at in that process, but we are working on Google Cloud, most definitely. Yep, for sure. Yeah, so the question is Docker data center. Docker data center is one of the tiers of the enterprise edition. So Docker data center is a commercial offering based on a annual subscription that gives you a graphical front end for managing containers. If you're a vCenter admin, think about vCenter for containers is essentially what Docker data center is. But yes, it's a paid offering. It's part of enterprise edition. You can get a through today free trial up on Docker.com.  If you're just using it Docker at home, you probably don't need it, honestly. But outside of the 30 day trial edition, I don't think there's anything like that. There's some open source projects out there and some emerging things. I think Portainer's one of them that kind of gives similar functionality, not quite as enterprise ready. If you just want a graphical front end, you might want to check one of those out for more of a hobbyist thing. I'm going to come over here and then I'll come back over here. There was a way in the back there. How does the AWS integration compare to ECS? So ECS is each C2 container service. It is basically the Amazon offering for sort of managing your containers up on Amazon. So a couple of big differences. One of the big differences is that the ECS integration uses, is always going to be behind as far as the Docker engine goes because they have to integrate it back up. So I think they're still like on 112. So with Docker for AWS, that release is part of the core release that we do. So when we release a new version of the engine, we automatically update that cloud formation template and all the omis behind it. The other part of it is that EC2 uses its own proprietary sort of chain, like a tool set or whatever commands. And so if your developers are over here developing on Docker on their MacBook and then it goes into EC2 container services, it's a completely different set of APIs and a completely different CLI. So you kind of break that workflow. Essentially they basically do the same sort of thing, but EC2 is a little more proprietary than say Docker for AWS. Like Docker for AWS is more open and leverages all the AWS stuff underneath it. Yeah, it's a really, really good question. So gentlemen's question was how do you relate or what's the practices around config management, puppet chef ansible and containers? And I think, I had a long conversation with the chef guys last week in container world about this. Most of those vendors are not gonna ever recommend that you put agents inside the container, right? That you wanna treat those containers as sort of immutable and they don't change. And so if you do an update to a container, that's a bad way to do it. You wanna update the stuff outside and do the upgrade. Puppet in particular has done a lot of work to help set up and maintain Docker environments. So that's sort of how I see the delineation, right? How do you build, they use them to build the infrastructure to maybe track the base images. Puppet has some tooling to do like manifest into Docker files. And then chef is doing this thing called Habitat, which is kind of cool because it's actually like a super set of everything, right? So it understands that containers are one way to put out applications, but there's also VMs, there's also physical applications. So they're kind of taking a more holistic approach, but most people, most of those companies, like when they get to the actual container, managing that, they leave that to Docker, right? They leave that to the Dockerfile and the images. So any last questions? All right, well, thank you so much for, oh, one more back here. Yep, in the Oregon sweatshirt. Yeah, gentlemen's question was what about the performance characteristics of different workloads and how would that impact the consolidation ratio? That example that I gave today is actually what we consider to be a fairly conservative estimate because that was a CPU bound application, right? And so applications that are more memory bound, you're gonna get better consolidation ratios than you will. So, but you won't know until you test the individual application.  And you're not gonna be able to do much about that. We find that like memory applications that are more memory bound seem to do a better job of consolidating. And applications that use a lot of storage, you can get really great storage savings because things, we essentially have something that's akin to deduplication or thin provisioning built into containers. Like containers are by their definition thin provisioned. So, if you scale them out, the more you scale out, the more you save in terms of disk space. Okay, all right, with that I have to stop because, not time for the next speaker, but thank you so much for coming out and letting me kick off scale. I was here last year, I loved it, and I'm glad to be back this year. Testing, testing, testing, testing. Hello. Testing, testing, testing, testing, testing. Testing. Yeah. But they were having trouble with it earlier than the sound guy disappeared. Hello, hello? I mean, if you have a chance to actually run and get somebody, yeah. Hello? Testing, testing, testing. Testing. Hello? Testing, testing, testing. Aha, there we go. Okay, now that's a different problem. Testing. Okay, no, just the one. Okay, wait, is this, it's still working? Yeah. Okay, awesome. Hello. I think somebody's here too. Okay, yeah? Yeah, okay. How are you here coming from? Yeah, yeah, he was just fixing that, so, okay. So let me actually do something else. Yeah. So I'm gonna ask you a favor, since I'm up here on stage, can you fill Donnie here with this when it comes to Q&A? Who's filled Donnie here? He was a talk show host and he would run around with a mic. Rocker. I need to type. Okay. Welcome everybody. This is Kubernetes 101. Let me apologize in advance for the static. The sound guys are working on it. But we are going to talk a little bit about how to use Kubernetes. The first thing I wanna say, this is scale's first container day as a scale thing. And I actually wanted to thank the conference committee who helped pick the talks for today and the scale 15 crew for actually making hosting this possible and that sort of thing. And next year we'll have sponsors and other stuff to thank, but not this year. So we'll keep this short. So this talk coming up is for people who actually know something about Docker. Maybe you've used Docker. Maybe you've actually developed some stuff on containers. But you don't necessarily know that much about orchestration or deployment or Kubernetes or whatever. I mean, really, I'm trying to address the question of, okay, so now I've got all my app is now in a container. So now what? Right? It's on the container, it runs on my laptop, but now I actually have to get it into production. So what happens next? So just briefly, the big background for Kubernetes where it came from and that sort of thing. Google is this thing called Borg. They decided to recreate the concepts of Borg as open source code. They made that compatible with Docker instead of their own internal container system. Then they contributed to the cloud native computing foundation as a project. So it would be non-profit independent. My employer Red Hat is a big contributor to that.  And individuals. And the big thing is one of the reasons why I deal with Kubernetes so much is that I work for Red Hat. Red Hat is this thing called OpenShift which is a complete CICD pipeline for development to production and containerized infrastructure. And OpenShift is basically a distribution of Kubernetes.  So now whenever you talk about containers, one of the things you always end up talking about is microservices, right? And the idea of a microservice is that for each service defined as some widget that does something, whether it is a web server listening on a port or a database server handling a data stream or a backup service or whatever, that service is going to be isolated to its own thing in the case of containerized infrastructure is going to be a container. But that means that for real production application, you are going to actually have a lot of containers. So for example, I've containerized Django applications for a while, right? And this is actually a reasonable stack for a Django application. You're going to have some PostgreSQL containers, right? So master replicas, et cetera. A database connection proxy. Oh, storage, PostgreSQL needs actually some network storage so it can be reliable for fail-downs, that sort of thing. So we've got Gluster running containers. Then we have the actual Django running containers under Whiskey, and then we have web servers front-ending that so it can actually be performant and do a little bit of caching. And then we have varnish or the reverse proxy up in front of that for performance reasons. Oh, and then we have to do some scheduled jobs like database backups and that sort of thing and pushing from get in that. And then a CI container to actually handle the pushes of the application every time we make a commit to the application. So excluding duplicates, that's eight different types of containers actually. Oh, wait a minute, nobody actually said anything here. Here I've been going on. I can't actually see these screens. Yeah, so I was dealing so much with the sound. The, yeah, how about some slides? Okay, so there we go. There are all of our things. So like eight different containers, the eight different types of containers and just this is actually sort of a simplified stack. So this starts to become a real coordination problem. It's like, oh my God, I've got 180 different containers and I have to coordinate them all and some of them over here and some of them there and some of them need external access and some of them don't. And you know what? I think I'm just gonna go back to the monolith, right? Just give me a VM or a VM and I'm just gonna go back to the monolith and I just, I understand that structure. So, and that was what we encountered a lot early on. There was actually why when we first saw like in the first year of Docker and that sort of thing, you know, you would ask you and say, how many people are using Docker for development and lots of hands will go up? How many people are using a production and like one hand would go up and that guy was working for Docker? And part of it was that there wasn't any way to coordinate all this stuff. And so we would talk about the microservices and everything, but nobody could actually deploy it because you're using, oh, bash scripts. Actually, I did multi-container deployment by bash script or using your configuration management system, you know, Puppet or Ansible or whatever it is or using some custom code or just typing real fast. These were all, you know, sort of popular systems but not really productionizable. So, but now with orchestration, we actually have a productionizable system. So I'm just gonna start at the basic sort of unit, right? Before we get up into doing the whole infrastructure, let's actually start with a small level coordination which is that sometimes you need a couple of containers to stick together. So an example of that would be, you know, something like, you know, a CDN and it's accompanying storage container running a network storage system or a database and a database proxy.  And for that reason, you wanna make sure that they always go out together. And in the world of Kubernetes, this concept is called pods. Far as I know, this is something that only Kubernetes does among the orchestration systems. I could be wrong. I know that Docker Swarm doesn't have a sort of pod concept and neither does MazeUs. But, you know, they're called pods and a pod is a group of one or more containers. They deploy together. These containers are their own sort of machine in that they share the same IP address on the network overlay that you have for your whole orchestration system. And a set of ports. So for example, if I've got a database, Postgres database and a database proxy together in a pod, the port 543.2 is gonna be allocated to the database proxy and you can't connect to the database directly. You have to connect to the proxy which within the pod connects to the database. And, you know, they'll share storage and other things that are connected. So let's actually take a look at that. So I've got this which is in my repo and I'll give you the address later on which are just some examples. So here's an example of a very basic pod because it only contains one container, right? We've got the AscentOS base image and it's running Apache HDB on top. So this is a very basic pod and you see it listens on port 80 as you'd expect from an unsecured web server. And that's it. Now, what I'm showing you here by the way is what I regard as the, there's a variety of different ways and I'll talk to them in a minute about how you can configure and tell Kubernetes to deploy things. And one of those ways and the one that makes best in my opinion for sort of long-term maintenance because you can check it into a Git repo is to use YAML files, which is what this is, YAML or JSON files, and load those into Kubernetes because it makes it very easy to track. It also makes it easy for me to show you things as opposed to doing interactive commands or other stuff. So this is just an example of a one container pod. Now, obviously the whole point of having pods though is that you might want more than one container. So this is an example from Kelsey Hightower where we're taking the Ghost Node.js based blogging platform and we're fronting it with an Nginx web server because it needs a web server to front it because otherwise it can only support one connection. So this is a case where you actually want two containers in a pod, right? We've got the Nginx container, we've got the Ghost container and if we're gonna have multiple ones of those, we're going to want multiple copies of that set for whatever reason and then they would share a database that would not be multiple copies. Yes, so that's a simple pod concept. Not only a two hung up on pods because you just get used to this because one of the things is you start out with containers and you say, oh, okay, well I want to deploy a container in Kubernetes, well no, you only need to deploy a pod. I mean actually, honestly, most of the time I end up deploying one container pods. The other reason why we need pods and containers is stuff that is transparent to you but when Kubernetes is setting up a lot of things like configuration and storage and other things that are built into Kubernetes, it actually launches utility containers within the pods that you don't have to manually specify but even though, as far as you're concerned, it's a one container pod, it is often not actually a one container pod. So, okay, so I've got this pod thing, so where am I sending it? Where am I sending everything? Well, our next sort of concept in Kubernetes word is nodes, right, and a node is an individual machine, either a real hardware or a virtual machine. You're gonna have several nodes in your cluster because this is the whole point of it, right, we're building a cloud unless you're in development in which case you only have one machine and so let me actually show you the easiest way to do that if you just wanna try this out. So, I installed something called MiniCube and MiniCube is an all-in-one VM that runs one instance of all the pieces of a Kubernetes stack so that you can try it out for development and you download it and it's available for a variety of different platforms and it's good for testing your Kubernetes stuff and that's how we're gonna actually do some of this other stuff and download it from there and if you'd rather do OpenShift, we also have one called MiniShift from the OpenShift team. So, but each one of those individual nodes represents a machine, again, hardware, virtual machine. The one thing that needs to happen in advance of Kubernetes accessing them is that each one of these machines needs to run a program called kubelet which is basically the Kubernetes daemon and then if you're running kubelet, kubelet can actually run everything else that's needed for kubernetes. On your various machines and those are your nodes. So, let's see if we are, we're not deployed yet so I'll show you that in a minute. Starting with VM, it's slow. Which is why I start containers for everything else. Now, obviously if you're doing clouds and you're doing orchestration, part of this is that you actually want to have a scalable infrastructure. So you want to take your application or whatever it is, right? I'm gonna have my web application, that sort of thing and I want to deploy one web server back by that code.  This is a plugin for Pokemon or something and so I need to actually deploy 150 of these and that's one of the other things that Kubernetes is going to handle for you. Now, the core concept in scaling out is what's called appropriately enough replicas, right? Which is you have a specification for, this is my pod right with a web server container with NGX or something in there and then I'm just going to tell you to scale out, deploy a whole bunch of these and possibly scale up and down. And all you're doing is sort of duplicating that and then you give Kubernetes instruction and Kubernetes runs a scheduler that decides where to put those. The default scheduler uses sort of a round robin algorithm where it basically looks at all of your nodes available, sees what the load on those nodes is and then starts deploying things to nodes that aren't heavily loaded. What that usually ends up meaning is that say if I'm deploying 16 replicas of something and I have 20 machines, the 16 tend to end up on different machines. But in the default scheduler that's not enforced unless you add extra information. So let's see if we've actually got, yes. Okay, so we've got Minikube up. So again, for development, Minikube will start up and it will configure, you also have to install the Kubernetes client, kubectl and it will configure kubectl to talk to the VM. So here's our node. We have one node because it's a VM running Minikube. So we're going to see our one node and then we want to go ahead and deploy some stuff to that one node. So let's actually take a look at what we're looking at in terms of replicas. So okay, so I wanted to show you my presentation. I do slides as JavaScript. So the slides are basically a web application. So we're going to actually redeploy the slides onto Kubernetes. So here we have, I've got something called a deployment and I'll explain what that is later on. This is not important right now. But here we have some information. You have to give everything a name to tell it, hey, this is the name for this thing so that later on I can delete it or scale it or do something else. And then here's the specification, right? I want three instances of it running, which would actually make a lot more sense if we had multiple machines, but we can test it here. We've got three instances running and then I'm going to give it some labels that allow me to find it later, which gets important when we get into services and I'll tell you that in a minute. And then I'm going to tell you what container to grab, right? So we're going to grab the container, jberkis, kube101, version 0.3. And then I'm going to have it listen on port 8000 because it's actually running the Python mini web server. So that's pretty simple. So let's go ahead and deploy that. So we've got deployments spinning up here and we've got pods and we're up and running. Now, obviously if I was actually deploying this for the first time, that would have taken a little bit longer because it would have had to download copies of the containers. But I didn't want you to wait through that, particularly not off of conference Wi-Fi. So that's sort of it for replicas and this allows you to actually sort of scale up or down and we can actually do things like, did I call it that? Yes. And so obviously we've just started up another one, so we've got four, right? Because you say, oh, these are all busy, I need to do more. Now, there is CPU based auto scaling built into Kubernetes. So you can also tell it, hey, anytime these are over 80% CPUs start deploying more of them. I'm not going to actually demo that, but just know that it exists. So that's pretty good, but there's a problem here. So I've got that listening on port 8000 Hold on, let me get the address. Okay, so I'm going to go ahead and try to listen on port 8000. Oh, that's a problem. Because what's happening actually with that port is that port is only available inside the Kubernetes system. Because in any microservice architecture, you're going to have a lot more services connecting to each other than you have available from the outside. So I actually need to tell Kubernetes how do I make this available from the outside? Or available specifically to other applications by name. And this is called services. So services are our wrapper that give you a way to access microservices by name and sort of a contained way from each other or access them from external networks from the web. There's also a second thing for sharing called ingress, which I'm not going to demo because it requires configuration with external DNS server, which I don't have set up. Which is designed specifically for web applications because it gives you path based access, HDB path based access where you have things like, well hey, the main application is at my app, but then I've got this other application at my app slash admin. For people who are familiar with Flask and some other things, it's actually fairly intuitive on that. So let's actually show. So this is the service. So again, another YAML file here, right? And I have to give everything a name. Names are scoped to whatever type of object it is. So you can actually reuse the same name. So this is, I have a Kube 101 preso deployment and a Kube 101 preso service. And this won't conflict because I have to tell Kubernetes what kind of object I'm asking for. And again, I add some labels and that sort of thing. You see, I'm not really making much use of the labels, part of the reason, in a real application you would because one of the things you can do with labels is you can use them as sort of search selectors for things. And then I'm going to give it a specification. Now, in a real production environment, I would have some kind of a load balancer set up in an external DNS server and that sort of thing. And then the service would hook into that. But I don't have that set up. So what I'm actually displaying this on is a type of service known as a node port. And a node port says, I'm going to allocate a port for my whole cluster that that port will be available on all the nodes of my cluster. And if anyone connects to that port, they will automatically connect to the service. It'll get redirected to the service. And then once I actually push this, Kubernetes is going to update a bunch of rules for the internal software defined network and go ahead and route that stuff. Now, if I were in a production environment, I would probably use a type of load balancer. I would have a load balancer plugin loaded for whatever load balancer I was using, whether that was Google Cloud's load balancer, AWS's elastic IP or whatever, or a Cisco thing if I'm doing internal sort of stuff.   But node port you can always play around with and it's a good way to test things. So let's go ahead and deploy that. So now, so I need to actually use that. So by the way, for node port, the IP address range it uses in the 31,000 to 32,000 range just for, you know, because it doesn't want to get restricted by secure system rules that require, you know, that reserve lower ranges, et cetera. And that's just the range that uses for node port. And there we have a presentation. Ta-da. Except there's going to be more to show you. But let me go off and do sort of a side thing. Now, this presentation doesn't require any configuration. But there are other things that do. So one of the things you need all the time is, for example, okay, you're going to have a different set of configuration for development than you have for production. Like for example, you're going to have for development, you obviously are going to have a whole different set of passwords than you do for production. At least hopefully you do. You're going to have maybe some other different, you know, sort of specs and that sort of thing in test and configuring the application and number of nodes and that sort of thing. The only thing you might be doing is if you're hosting an application for somebody else, you might want to actually create multiple instances that application tailored to each one of your users, right? So this is Joe's web app and this is Mary's web app and this is Rashi's web app. And in that case, you're going to have a different configuration for each one of those. Plus you have to do things like set passwords. Sometimes you want to tweak performance settings and that sort of thing. And so we need some configuration methods. Now there's three main methods in Kubernetes. One is you can pass environment variables to the inside of the container. A second one is something called config map, which can be passed into the container either as environment variables or as a file. As long as you can support the, you know, the variable, as long as your application will support the simple INI file sort of format. And then there's secrets and the built-in secrets in Kubernetes is an obfuscated password facility for a real production quality secrets. You would actually use a plugin utility like Cache and Corpse Vault that actually has robust encryption and automated rotation of passwords, et cetera. So let's actually show you a couple of those. So I'm not going to actually demo these. I will actually be demoing them tomorrow for anybody who's at the Postgres Day tomorrow. So this is for a scalable Postgres on Kubernetes thing. So this is an example of using the secrets facility, which just has hashed passwords.  And then if we actually look at, is this the wrong copy? This is probably the wrong copy. Okay, hold on. Ah, there we go. Okay, we're just having scrolling problems. Okay, so ignore the rest of this, but then we have, you know, this sort of thing where, again, because of how I've set up the Petroni application, it still wants to read these things as environment variables. And so I'm passing a number of things. I'm passing some things as raw environment variables like what is the name of the cluster that I'm joining? This is cluster of Postgres nodes. And then we have other things that are gonna be pulled from somewhere else. Like for example, these passwords are getting pulled from the secrets facility. And so I'm referencing them by name and then they actually get passed along to the main servers. And then all of this gets loaded in by a startup script within the Petroni node so that the individual Petroni node gets configured correctly. So, now I did show you some database stuff and the whole reason I got involved with Kubernetes to begin with was that, frankly, I wanna run databases on the container cloud. This is what I do. So, stateful services are a big thing for me. So there's a couple of different, a couple of different facilities that you need to talk about in Kubernetes. So one of the Kubernetes that's out of the box is the ability to actually manage storage. And in the Kubernetes dictionary, there are two terms for this. One is volumes. And volumes refer to local storage on the node so you can actually have a container write some files individually to the node in a directory allocated to the container, usually in Docker's storage space on the system. And the second thing is persistent volumes, which is what you're gonna use for more production thing. And persistent volumes attached to a Kubernetes plug-in for whatever you've loaded that will write to shared network storage of some kind. So that could be Gluster, that could be SAP, that could be EBS, that could be the Google storage engine, that could be whatever you have that is providing storage to your cloud instances or the shared storage that you built. And the reason that persistent volumes focus on shared network storage is that, of course, one of the things that we need to be able to do with pods and services and everything else is relocate them across our cluster. And if we're storing only things in local storage, then it becomes up to the application to handle moving that data instead of it being available via Kubernetes. Now, there's a whole facility sort of beyond this called Stateful Set. And Stateful Set makes use of a whole bunch of other things in order to handle services that have a lot of Stateful data like databases, including persistent identity and routing and associating storage with particular instances of running pods and that sort of thing. And I will be talking about that tomorrow, specifically focused on Postgres and on Sunday, which I'll be talking about Stateful Set in general and the theory behind this design and what it does and what it doesn't do. So that's gonna be all for that for right now. So let me actually, I'll show you something briefly for that. Oh, that's right. So here's a more easy example. This is just setting up a persistent volume as an object to make it available for pods to use that is for Amazon EBS. You know, and you're basically allocating a particular volume on EBS to be available for storage for that. And then you can actually reference that within the individual, you can reference that within the individual pod definitions as this is where my storage is for this pod. So, okay, so that's great. We've got everything set up. We've got it deployed. We have initial application deployed. But now, well, let me show you an example of this problem. Does anybody see what's wrong with that presentation? Yeah, this is the version of this I gave at Faustum. Well, it's not what I want for here. This is scale. I need the new version of this. I need version 0.4. So what am I gonna do about that? Well, so in Kubernetes 1.3, I think, we introduced deployments. And a deployment basically represents as an object an instance of an application. And it has some sort of continuity of identities that, hey, I deployed this application that's got these six replicas of this and these four replicas of this other thing and these services, et cetera. And so that is an instance of my application and then I can actually modify that at runtime and update it. And one of the things that does out of the box is it supports rolling updates. Like automatically, if I tell it, okay, I want a new container for X, it will by default replace one at a time instead of bringing the whole thing down and then bring it back up, which is generally what you want. And if you want to modify the behavior of rolling updates, you can actually specify a bunch of variables about how many to replace set of time and how long to wait and that sort of thing. But let's actually just do a simple rolling update thing here. So, okay. So, in this case, I've got, I had the wrong version here. So I actually want version 0.4. That did not take long at all. So you can see right there, it already killed off the three old versions of the pod and is bringing up three new ones. Actually has brought up three new ones. So let's see if that worked. Oh yeah, there we go. Yay. One of the other things that I actually did because I didn't go back, I didn't reset the number to four is it actually killed off four instances and brought up three because that's what I had in the file. Okay. So let's get back to where we were. Okay. And that's your basic functionality of Kubernetes in a nutshell. So there is a lot more things that you can do with Kubernetes and a lot of special features and a lot of plugins and a lot of other things. But I mean, frankly, if you just actually figure out pods, replicas, services and deployments, then you're actually already ready to use Kubernetes for something real. And it doesn't take long to actually learn that. Now, so you can talk a little bit about how some of that stuff works. Just in case, because early on, when Mike was asking questions, we've got a lot of sysadmins in the room. And so for your sysadmins, you wanna know what's actually gonna be running here. So for Kubernetes, you're going to have one or more master nodes. And the master node actually runs a whole bunch of different processes. There's going to be a connection to an ETCD cluster. ETCD is what's known as a distributed consensus store. It's a way to actually have consistent data that is nevertheless available across machine failures. And so you'll have three, five, seven nodes of ETCZ that you need to connect to. You're gonna have an API server, which is what everything else in the system connects to. Is that API server? So again, I'm using kubectl. It is connecting to the API server to do all of its stuff. You're gonna have a scheduler at schedule services.  And then that connects to all of your nodes and your nodes have the kubelet running on it. Docker, at least at the present time. In the last, actually right now, you can do Rocket also. If you're into CoralS Rocket, you could actually use Rocket instead of Docker. And a proxy service that plugs into the software defined network to make that node part of the internal Kubernetes cluster network that's there. And by the way, people say it's like software defined network and network overlay and that sort of thing. It's really just a bunch of IP tables rules.  It's not actually that complicated. So, EGCD, Distributed Consensus Store holds metadata. It allows you, for example, to switch where if you lose your Kubernetes master, you can bring up a new one quickly and automatically because it just needs to connect to EGCD because that's where all the data is. The, now, what I was showing you in terms of how to modify objects and manage Kubernetes was using YAML files, which I said, I support because I find it's the most sustainable way to actually work with it because you check all those and to get your application is version controlled, everything else. But that's not the only way to do it. For example, if you have a valid connection to the EGCD cluster, you can just update the JSON in EGCD itself. And if you update the JSON, those changes become real on the Kubernetes cluster because the kubelets are polling for changes all the time. You can write a lot of kubectl one-liners if you just need to deploy a basic container image. You can just do that, kubectl, create whatever. You can do the YAML file things there. The only thing you can do is that it is an API and so some programming languages like Python have drivers for the Kubernetes API. So if you would rather write your deployments as Python code, you can do that. And there are reasons why you would want to go ahead and do that. And there will probably be, as Kubernetes gets more mature, people will probably develop even more editing utilities. And of course, you can use a more sophisticated system on top of Kubernetes like OpenShift that lets you manage a whole cluster through a more user-friendly system. So there's a whole bunch of these other, because of course we believe firmly in the microservice architecture in the world of Kubernetes. And so for this microservice architecture, we have everything within Kubernetes runs on microservices and there's other things that can go over like the DNS servers and because we have to have internal DNS so that the services can connect to each other and all these other things. So to recap, the things that Kubernetes does, right, is we group stuff through pods, we deploy stuff under nodes, we scale out using replicas, we share stuff, all of our microservices using services, we have a variety of configuration services and we have volumes for storage. The, there are some other, whoop, you know what? I apparently uploaded that too soon. We're missing a couple of bullet points there. There are a few other Kubernetes things. Federation for doing multiple data centers. There's now something called Helm, which is a different way to configure multi-container app to template multi-container apps. I, CoreS, one of the things I've been excited about CoreS has been working on this thing called the operator pattern for expressing application semantics through Cube, like you wanna say, hey, I wanna actually call the Postgres object through Cube and tell it to backup, you know, through the Cube API. And so that's actually pretty cool for me because of what I work on. There's ways to run Kubernetes without Docker if you have some reason to do that using like RKT and this very alpha thing called cryo and that sort of thing. We don't need to, you can look those up later online. You don't actually need to know any of those things to run Kubernetes. I mean, the big thing that Kubernetes does for you is it lets you turn a set of containers into an application that you can deploy and that's what it's for. So, questions? Yep. Okay, right over there. One of your slides, I noticed you had, the one that you said for like CIS admins, I noticed that you had your control plane and your workers are two separate entities. So, assuming that there is some kind of network connectivity between the control plane and the work plane, there is no reason, there's no requirement to co-locate those services, correct? Right. Correct, there's no requirement to co-locate them. Generally, your Cube master or masters will be running on their own machines or virtual machines just because they have a lot of load running the Kubernetes system itself. Do you follow me? So you don't necessarily want them running an application workload that might use up all of the CPU or the RAM on the machine. And that's caused the whole Kubernetes system to slow down. That also ties into another question that people get a lot where they say, okay, we're running ETCD for Kubernetes. Can I use the same ETCD cluster for applications? And the answer is yes, you can, but it's a bad idea because if that ETCD gets so busy with applications that it can't answer Kubernetes requests, then you as an administrator can't do anything about that because you can't shut down the services because Kubernetes is not responding. And so you can actually, like in Minicube, I am running the applications in the Kubernetes master stuff all in the same VM, but you wouldn't necessarily want to do that in production just for reliability reasons. So we've got somebody else over here. How does it connect in with a large physical load balancer? Do the services add sort of network hops and latency, where does it go directly to the containers themselves? So the first question was, how does it access a large load balancer? And that's through the load balancer plugins.  Generally, if you use like the prescribed installers on AWS or GCE, well, GCS Kubernetes is built in. That automatically plugs into their load balancers in their cloud. If you're using a hardware load balancer, then you're going to need the plugin for that. I don't know the whole universe of plugins and what's supported and what's not. You just look. There is going to be, there is necessarily going to be some extra latency because generally you're adding an extra hop or two in connecting to the services, right? Because you're going to connect from the load balancer to one of the Kubernetes nodes. And then the service, then the pods you want to connect to may not be on that Kubernetes node and so you have an extra hop. And most of this runs through IP tables, rules, et cetera. So it's pretty fast on the individual machines, but you are adding extra hops. And so if sub millisecond latency is your problem, then yeah, you're going to notice. Most people don't notice. Okay. So you mentioned that there's an API for the Kubernetes platform. If we're already using something like Salt, per se, would we be looking at using maybe a state or maybe a formula in Salt to connect to it? Or would we be, or is there something in Kubernetes that you can use to connect to a configuration management system? It would go the other way. You'd be looking for a module for Salt that actually has Kubernetes support. And one of the questions actually we had for the last speaker was, how does configuration management fit into this? And different people have different ways that they deal with this, but from my perspective, I do a lot of Ansible, and I use Ansible to manage Kubernetes. So what happens is the configuration moves to a more centralized role, where you use it to build, you know, build my templates for my applications and that sort of thing and manage Kubernetes. I know Ansible is a plugin for Kubernetes. I don't know if Salt has a module. So just look on Salt for that. Yeah, okay. How would I interface with LogStash or other logging infrastructures? How would you interface with LogStash or other logging infrastructures? So that's an example of exactly where pods are a useful concept, because what you would want to do is in each of your pods, you run LogStash as a pod and actually have it collect logs from the other containers in there. I mean, there's one way to do it. The other way to do it is obviously all of these containers, if they have been built correctly, are dumping stuff to standard out, which is getting collected centrally on the machine. So the other thing you can do is you can run something like LogStash as what's known as a demon set. And a demon set is simply a special type of pod that runs one per physical node. And so you would run LogStash as a demon set, so there'd be one in each node and those would forward to whatever your central log application is. I had a question. Do you see Kubernetes and Docker kind of solving similar problems? And if so, what advantages does Kubernetes have over Docker? Okay. So Docker engine operates at a different level than Kubernetes. And like I said, in the example I'm showing you, Docker engine is what's running on the individual nodes. Docker swarm is the thing that is the direct alternative to Kubernetes. And there are some different architectural decisions there, like I mentioned, Docker swarm doesn't do pods. And Kubernetes has pods. There's some different architectural decisions. I'm not actually all that familiar with the architecture of swarm inside. And even less familiar with some of the other alternatives like Mezos and the thing from AshleyCorp. In a lot of cases, with any of these distributed systems you have to make a lot of trade-offs. And so having all of these different teams working on different versions is really helpful because it lets people try different trade-offs and see how they work out. But other than that, the nice thing about it all being open source is give it a try. If you're not sure about Kubernetes versus swarm, try them both. In your example where you updated the slides, I'm wondering about like say, would you run Kubernetes in local development where say you had a front-end that's dynamically compiled like watching files and compiling JavaScript and you have a server that you're working on that code and it's restarting the process, would you have to like rescale up those nodes in Kubernetes or is there a way for you to have live updating while you're developing locally or is that just not a use case that you would use it for? So, I mean first of all, if I'm doing full CI CD, that would be a reason for me to use OpenShift because that's one of the things that OpenShift adds to Kubernetes. And the second thing is it doesn't really affect scaling because like say if I have 20 instances of this application and I do a commit and that's a new version of the application and the CI CD is going to deploy it, when it pushes the deployment, it'll do a rolling update. So it'll replace those 21 at a time. Was that your question? I'm not, ah, okay. So question if you're developing locally and you want to have it update as you're coding. I've actually seen that. I know Dusty did that as a demo with OpenShift which is based on Kubernetes and some code. I don't personally know how to do that though. So if you want to ping me by email or something like that, I can actually connect to you later on. So from creating a cluster point of view, would you rather have, so if my application, like different applications have different resource requirements, would you create a huge cluster of same type of instances or would you rather have different clusters for different type of instances? Okay, so I don't know if you were in the first talk but I'm gonna give you the same answer that Mike gave earlier, which is it depends. Because really the question is what, how different are those different requirements, right? If different applications just require different amounts of CPU and memory, there is a whole resource allocation thing built into Kubernetes that operates through Linux C groups where it'll, you know, where you can tell it limit this to X amount of memory, et cetera. But if they're different in, hey, this application actually needs GPUs, then you're probably gonna wanna handle that in some special way. Now there's two ways in Kubernetes to handle that. One is you can add labels to the nodes. Like I said, these are the GPU nodes, add a label and then run a custom scheduler, which sounds scary but there's actually a whole toolkit in Kubernetes to customize your scheduler that actually pays attention to those labels when it sends applications out. The second way that you can do that is federation. That is in general Kubernetes federations intended for people who have like say distributed data centers, but if you have like this set of machines that have super fast, large SSD storage and this set of machines that are more generic, then you can actually, even within the same data center, have two different Kubernetes clusters and federate them. So, and which of those makes more sense for you is gonna depend on sort of finer grain things. And this will be the last question. What would you say is an easy way to expose this as like a self-service tool for say like development? Okay, what would you say is an easy way to expose this self-service tool for development? Well, again, I'm gonna bring up OpenShift because that's what it's designed for. OpenShift is designed to be a multi-tenant system among other things so that you can actually give people application access and they have access only to their applications. If you wanna come by the Red Hat booth, probably tomorrow afternoon, certainly on Saturday, I'm actually gonna have a little tiny OpenShift cluster running and I can actually show you more of that. Okay, well thank you. And we have another speaker coming up next. Thanks. Okay, if everyone would take their seats, we're going to start up here. So our next speaker is Murley from Rancher Labs, who is a network guru there for RancherOS. Is that what you were looking for? Rancher. Yeah, for Rancher, okay. And he is going to give us a practical use case for refactoring or how to refactor to microservices. So welcome. Thank you. Thanks for the introduction. Thank you everybody for joining me today. So here is the high level overview of my talk. So we'll start with the introduction and we will go over what microservices are and why we need microservices and how do we build or refactor microservices. And I will share some of my insights, lessons and tips that I've learned so far in the past, year and a half that I've been working with microservices. After that, let's containerize one of the applications and open source application called FreeCodeCamp and let's see if we can run it. A little bit about myself. So I am the principal software engineer at Rancher Labs. So what I do is I build pipes. So I build pipes between various containers so that you can send data across. Just like Mario goes inside a pipe and then he shows up in a different world, you could send data from one container and it shows up magically on the other container. That's what I do. I take care of the plumbing. And you can see my contributions on GitHub. I work on a bunch of networking things. So one of the recent works that I worked on is I built a new microservice which takes care of securing the overlay networks. So if you're a good guy and you're not supposed to enter a pipe, I'll tell you nicely, hey, you cannot do that.  And some of the other works that I worked on is I refactored IPsec and created a new microservice using VXLAN overlay. So just to give a quick overview, IPsec is an overlay technology, networking technology that is used for public cloud. So if you are sending data from one cloud provider to another cloud provider over the internet, you would want to use IPsec. So it's like Mario on Superstar. And if you want to use networking within your data center and you know it's secure, you would want to use VXLAN. So it's like you just zoom through it. And I am talking more about networking this Saturday. So please feel free to join.  You know, I'll just not go through this. Okay, so what are microservices? You know, I went online when I first started working on microservices, trying to understand, okay, what microservices are. Okay, here are the different definitions. A microservice is a specialized SOA architecture, okay? And what exactly is a service? A service is something that's providing a need or a value or you know it's doing some kind of, I don't know. And what exactly is an application? An application is a group of services, okay? And what is a monolithic application? An application that is big, that's just one. That's simple, right? That's what I felt when I started reading. Well, do you get it? This was my reaction when I first started jumping into microservices. So I wanted a more practical example. You know, I like things, you know, head first way. So, okay, sure. So let me explain my way of explaining microservices. Where is Mario, by the way? So he found his co-founder and they are on to a much difficult quest next. So let's begin the next quest. So the quest is, you know, the same dream that we all share, you know, we want to build a multi-billion dollar company. You know, of course, we want to change the world on the way. So Mario wants to, you know, start a company. So he looked around, okay, I have a castle and let me bootstrap with it. So I want to build a bed and breakfast company. So I have, you know, different services that I can offer. I can offer the bedrooms in the castle. I can offer kitchen, the dining room, living room, et cetera. So he fit in a bunch of beds in the bedrooms and started this B&B business. It was a hit. You know, people loved it. They wanted to visit the castle and, you know, people, the demand started flowing in. And then Mario hit a scale problem. You know, he had only so many bedrooms that he could, you know, put it out. So he wanted to scale, you know. What was one of the options that he had? He used the magical mushroom. Just, he made the castle much bigger. So he just threw in more beds in that and he was able to scale. So this is an example of how some of the services or some of the applications, which have been built in the past, scaled up.  You throw in more storage. You throw in faster networking. That's how you were able to scale.  How do you scale further? So the next solution is, okay, I want to buy more castles. Just throw in more servers. But here, the problem is Mario's business needs more bedrooms. So that he could accommodate more people, more guests, more customers. But if you buy a castle, you have an additional overhead of kitchens, of dining rooms, which are not so useful. So the next, you know, solution, you know, a good solution for Mario would be, take the same castle, just scale up only the bedrooms, which are the most needed. So this is one of the ways I could understand what a microservice is. You know, there are like, a lot of services in an application. And, you know, if there is one service that I would like to scale up, and if I could detach it from the rest of the application, you know, it's something called a microservice. So that's how I explain it to myself and I explain it to others. So, you know, with this model, with this microservices architecture, what you could do is, you can just scale only the services that you need on demand. You know, you can scale up, you can scale down. So to summarize what we have seen so far, a microservice is something independent. It can exist on its own. It does, it needs help of other things, but you know, it can live on its own. And it's flexible. You know, you can scale it up, you can scale it down, and you know, you can move it around like you can move one of the microservices from one operating system to a different one, things like that. It's very flexible, and it's very replaceable.  You know, tomorrow he comes up with, oh, there is a new building material that I could use to build the bedroom so he could just replace it. So in the same way, microservices, if they are implemented today with Python or some other language, you could just replace them with a different programming language, a different implementation. You can refactor them easily. And microservices are upgradable. So what it means is, if you have a certain version of microservice and you want to add a new functionality and you want to, you know, make it run faster, you can put it in a new microservice and swap it out. So that's an upgradable services. So these are some of the good things about a microservice. So why exactly do we need microservices? So from the discussion so far, one thing is quite obvious, you know, when companies or when teams hit scale issues, that's when they start looking for solutions and microservices provide a good way to scale up. So the other way we could look at of, like, you know, answering this question, why do we in microservices is look at the problems of a monolithic architecture. So what happens in a monolithic architecture? You know, one of the telltale signs of a monolithic application is you have a large code base and you have a lot of developers hacking, developing stuff on the same code base. What happens when you have, like, a huge code base? You know, I'm sure you must have used IDs in the past. If you have a big, giant code base, it takes a long time to load the ID. And when you are trying to make changes, when you are trying to run, it becomes very difficult. And also, it's kind of difficult to manage different developers to work on the same thing. You know, oh, I need to get in this feature. The other developer wants to get in his feature. So how do you coordinate? So you need management teams. So you have a lot of overhead. And if one of the developers decides to upgrade one of the packages, it just, oh, I want this new feature, I'm gonna upgrade this package. But what happens? You know, the other developer is using the older version and it just breaks. So these are like some of the problems during the development process. And once you have this application deployed in production, if there is a problem, what happens? You know, there could be teams who would be blamed or who would be brought in to analyze, okay, what has broken? And most often, it happens that the teams who are not responsible for the breakage end up debugging the whole thing. And those people may not have the expertise of where the problem lies. So what could take a day for the right team? You know, it could take a week for the wrong team to debug it. They would definitely debug it. But you know, from a developer perspective, it's great. You know, I'm learning, you know, other modules in my product, and I'm expanding my breadth, but that's not good for business. You know, think of if your service is down for a day, that's really bad. And when things go wrong and you fix them, and finally, you know, all the XX come back and then they ask, hey, what happened? Why did we have an outage for an hour? Then, you know, nobody wants to take responsibility.  Everybody starts pointing around, oh, it's that team. It's this team. But on the other hand, if you had like an outage for five, 10 minutes, you know, you just fix it, and then if it exists as, oh, it was just a down time for five, 10 minutes. So why microservices? If we look at the opposites of the problems, you know, these are some of the good things of microservices. So you have small code bases, they are much easier to manage, and you have a small team, and the appropriate size of the teams working on these code bases. And generally, it's proven from, you know, research and experience across the industry that, you know, the right team size is about, you know, if you can feed your team with two pizzas, that's about the right team size, you know. It's perfect. It works, you know, as a well-oiled machine, you know. There's not too much free space, and there is not too much friction as well. It's perfect. And the teams of this size tend to deliver stuff much faster, with much high quality, and, you know, a lot of good things. With microservices, the advantages is, you know, each of these microservice can be built, tested, and, you know, scale independently. You don't have to worry about, how do I, you know, coordinate with the project managers, or how do I deal with other teams? How do I communicate? How do I get these approvals? How do I deal with the conflicts? You don't have to worry about it. You just focus on your microservice, get it up, and running. With microservices, you know, we have clear separations. So when there is a problem in production, it is very easy to debug. You know, you look at the logs of the different microservice, you can just easily, very easily tell, oh, it's the DB which is having problem, or it's the networking which is having problem. In the past, in my experience, you know, when something doesn't work, the first thing people used to do was call the networking team. I was like, okay, everything is broken is because of networking. I jump in, I start looking at the logs, start debugging, and then finally figure out it was not a networking issue. It was a problem with something else. So these kind of things can be avoided when you are using microservices. And the other good thing which a lot of developers love about microservices is they can bring whatever language they are comfortable with. You know, if you have one giant application which is built in Java, and if you happen to be a person who likes Ruby, or you like Go, you are forced to work on Java. But with microservices, you can bring in your own language. You can bring in your own tools. So it's more empowering. With microservices, the advantage, the other important advantage is refactoring becomes much easier. Because each microservice is independent, you have tests which are specifically written for this microservices and you can run them. So when you refactor, you will get an immediate feedback loop whether the tests pass or fail. So developers are more confident when they want to improve an existing microservice. With all these things, the CI CD pipelines are easier to build and use in companies. So are microservices are the best thing in the world? Are they free? Of course not. Everything comes with a cost. So the first cost is the complexity that comes with running a large number of microservices. Earlier, if you had a monolithic application running on one server, all you had to deal with was like, okay, I have this four or five different processes, four or five different logs. Can I do PS-EF and then figure out what's going on? Things like that. But now imagine you have 10 different microservices running on 10 different servers. That means you are looking at 100 different things running in production and they are very hard, very complex. They need more resources to be managed. So you have a lot of overhead when you deploy microservices. And for taking care of these microservices in production, you need ninjas. You need to bring in the experts. You need your team to be well-versed with the best practices. And they should be provided with all the right tools to be able to debug and enable logging, security, a lot of things. There's an additional overhead. And the important thing with microservices, with microservices architecture is the microservices talk to each other based on contracts. So if one of the contract is broken, if one of the API changes, it can have a cascading effect, just like dominoes. If one thing fails, it can just create havoc. It's very similar to monolithic application, but at least in microservices, you can protect yourself. You design microservices to handle failure. The other disadvantage is because you have developers working independently. Sometimes it happens that you end up with duplicate efforts. Two developers working on the same similar feature, they create similar libraries, and there's a duplication of effort. Testing challenges, this is very interesting. Although microservices can be tested standalone, but when they go into production, you do not know how many of them are running. It could be 10 or it could be 100, or when there is no load, there could be only one. And a certain problem can happen only when you are scaling about 10. So to recreate this kind of topologies, the kind of setups in-house during testing is a challenge. You cannot predict everything. So these are some of the costs of running microservices. So it's not free. To summarize whatever we have seen so far, we have the monolithic where everything is packaged together. It scales together, but microservices are individual. You can just scale only the services that are needed. And the release cycle in a monolithic app is larger, whereas with microservices, you tend to be more agile. You can release stuff faster. So it's easier to build scale with minimal infrastructure and computing resources. So now that we have seen what are microservices and why some of the people are motivated to use microservices, let's see what are the factors you have to consider when you build or refactor some of the microservices. If you are building from scratch, if you are a new company or if you are a new team, if you have a chance to start working on microservices, the first and foremost thing that you have to do is you have to plan. You have to come up with a design. You have to identify what are the responsibilities of this particular microservice are. What other microservice does it depend on and what other services depend on me? So you have to identify the interfaces much ahead of time and you have to write your unit test first before you write code. This is one of the most important things. Like I mentioned earlier, different microservices talk to each other based on contracts and you cannot break those contracts. And sometimes you have to break them so that you could provide new functionality and you can come up with a totally different one. So you need to come up with deprecation policies and you should have proper documentation for all this stuff what each microservice is offering, how it's going to deprecate and how you need to update and things like that.  If you have to start chopping up you could end up with very small microservices for nothing. Like you can end up with like 100 microservices. It would be overwhelming. So just find the sweet spot where you can divide your application into the right functions. It need not be like, okay, I'm gonna have logging as one microservice, I'm gonna have UI as one microservice. Think of it as a microservice is providing some kind of functionality. It can come up with a UI, it can have its own logging but it does one thing and one thing well. That's how you identify what to build as a microservice. And just because you have an option to use whatever language you want, and let's say you are building like five different microservices in your company, you can start using five different languages. Each developer can bring in their own language but it comes with its own drawbacks. If one of the developer moves on to a different project or a different company, the other developer taking up that microservice for sustenance and maintenance he will have a tough time. So probably if you could stick with two or three languages that would be good. But if you have 10 different languages it would be very difficult. And the most important thing when you are building a microservice is be prepared for failure. Think of all possible failure scenarios during your design phase. What if this happens? What if I can't connect to the database? What if my dependency microservice doesn't start or it doesn't show up? How do I handle it? How do I handle failures gracefully? It is one of the most important things. A lot of developers just move the normal application into microservice and they forget about failures and when they take this microservice into production it fails very badly. So please be prepared for failures. It's not about why failures will happen or will they happen. Most of us who have experience they know that failures are definitely going to happen. It's just a matter of when they will happen. And at this point this might seem a little off topic but I would like to talk about Conway's law. What this law talks about is in an organization whatever is the hierarchy of the structure is generally the design of the software follows the same pattern. So let's say you have one architect who has like six or seven developers and if all of the developers are talking to the same architect the architecture of the software that they are building tends to be the same. So this law is very important. The reason I am bringing it up is when you are building microservices you would want to empower your teams who are building microservices. You want them to be independent. You want them to learn from their mistakes. You want them to experiment. You want them to fail and learn. So that way they can iterate faster and they can build stuff in a much better fashion and a much better way. So if your organization is not encouraging the teams to take their own decisions even if you start using microservices the design of the overall product will represent your organization structure. So if one of the teams is responsible for getting all of the releases your design will follow something like that. There will be one bottleneck. You would want to give freedom to all the developers and make the best use of their talent. Now if you are not building from scratch and let's say you are already having a legacy application and you are having scale problems or you are trying to refactor this application at this point you are trying to evaluate if microservices architecture is the right one for me or not. The first question that you have to ask is are microservices the right thing for me? You could be having scale issues. So if it is something that you can solve by having the mushroom like just throwing in more resources probably you don't need a microservice. You could just live with the same monolithic architecture. But if you have really the scale issues that's when you have to decide okay microservices is the way for me to go. The first step is when you are refacting an application is you would want to repackage your existing stuff into smaller pieces. That's the low hanging fruit. Identify the different components in your monolithic application and start packaging them separately. That's the first step you could do to move towards a microservice architecture. The thing with the existing apps is you cannot just change them overnight. It takes time to evolve to microservices architecture. So you have to support the old one as well as the new one while you are trying to switch over to the new one. So it takes time. So start with the low hanging fruits and then iterate. So after you are done with repackaging the next step would be analyze your code. Where exactly are the bottlenecks? Which are the functional areas that I can separate it out as a microservice. And after that think of scaling it. Okay now that we have a microservice architecture which of them needs scale. And with scale we need more resources like you need to have logging infrastructure. You need to have monitoring infrastructure. You need load balances. So those things come much later. And once again even when you are refactoring please be prepared for failure. Implementation details. So how do we deploy microservices? How many of you have not heard about containers? Wow, nobody, everybody has heard about containers. How many of you have not heard about virtual machines? So to deploy microservices you don't need to use containers. You can deploy microservices with virtual machines. But it's just that containers are a good way to build microservices and to deliver them and to scale the microservices it's much faster. So this is my slide to understand what microservice or what containers are. They're like virtual environments that share the same host operating system. And because all of you know about containers I'm just moving on to the next one. So this is a slide that I had to explain what VMs are and what containers are. How you have an additional overhead of the guest operating systems when you're running VMs. Whereas in the container virtualization you don't need the operating system in each of the guest OSs. What are the different runtimes that you would choose when you are trying to run your microservices using containers? You have RunC, you have LXC, you have OpenVZ, you have Rocket, you have Docker. You have a lot of options. Pick what works for you. One of the most popular runtimes that all of us are familiar with is Docker. The Docker's mantra is you build once and you can run it everywhere. So this mantra has what made it so popular. You could just build on your local laptop and you could use the same Docker image to run on cloud as well. So how do we run containers? So the first thing is you have to pick a runtime for the stock I picked Docker. And the first cycle, the first step in running containers, you have to build a container image. A container image is like a blueprint. You know, it's, think of it like as a cookie cutter.  And when you have built this cookie cutter, when you would want to use it in different places you have to store it somewhere where you could use it. So that's the Docker Hub. And once it is on Docker Hub, you could pull it in private or public clouds and you could run containers. So this is the kind of the life cycle of how you take a spec of how you want to build the microservice, how do you build the image, how do you push it to the Docker registry. You can run it in public and the private cloud. There are so many options available today in the market. These are some of the open source tools. Some of them are closed source solutions. So you have a variety of choices for various things. So I want to share some of the insights and other things that I've learned along the way. So the first thing that we have realized is converse law is not just theoretical. It is true. We have really experienced it in our own company. And I have these slides. I have put in all the lessons. If I just talk about each of this, it's like there's no context to it. Just like the way if I talk about what a microservice is or what a monolithic application without giving you a practical example, it's kind of difficult to get the context. I had a debate yesterday with my marketing team if I should have the next couple of slides or not because it's like talking about the product, about what I have worked on. But my take on this is I'm not pitching the product, but as an open source developer, I want to share what I worked on. And when I build a context, that's when other developers can appreciate what I am talking about. And they can learn from the experiences and because it's open source, you can look at it. And it could be useful for you when you are trying to build your applications. So a high level overview of the product that I worked on is it has a management server and the main responsibility of this product is to run containers at massive scale in production. So we have ability to run containers on different clusters. They are like isolated clusters. So if I zoom in a little bit, this is one particular cluster which is managed by the management server. So here, the thing that I wanted to highlight was, you see the blue container running in the management server? It has multiple processes. So these are like different modules or different services running in one monolithic application. And if you look at the compute node, we deploy services of our product on the different nodes inside containers. So this was like the first low hanging fruit that we attempted at, like, you know, just put everything in containers. So we started running different stuff in different containers. We started with two containers. So here, what happened was, even though we had multiple microservices, the architecture of this was all of these small components they were communicating to the management server. This one. So when we look back now, after we have evolved into a newer architecture, we realized that that was because of the way the hierarchy was working in our organization. So we had our architect, chief architect, working on this management server and the different teams were communicating with him. So when we developed the microservices, all we had to do was use the APIs exposed by this central piece of software and run on top of it. So there was no independent nature. I mean, we were independent to a certain extent, but it was not scalable. As all the microservices running in the different hosts or the different compute nodes, they were talking to the same central entity we couldn't scale. So we came up, that's when we realized, oh, sure, the converse law is really true. So we need to change the hierarchy of the organization. So we made some changes. We empowered the small teams that are working on different pieces of the software. Okay, you develop, you take care of the stuff and we have to change this architecture. So what happened later once we changed was we broke down the different pieces or the different components into different microservices. And here one key thing that really enabled us to be independent was the introduction of the locally available distributed data. So what it means is the reason why the different pieces of the software were talking to the central management server was you want to get data. So what we did is we, instead of pulling from the central management server, we changed, we reversed the roles, we pushed the data into something called as meta data. So these services, instead of talking to the central entity, we started talking locally. So that really enabled us to move to the microservices architecture. So because of that, the teams became really agile. We were like releasing much faster and we came up with all the best practices, come up with common libraries so that other microservices could share and we fixed upon like one or two languages instead of having like 10 different stuff, things like that.  One of the things we did was let's break up this monolithic application into smaller pieces and run in microservices. We did that, but we ran into a lot of problems. That's when we decided, okay, for this piece of software, it's a bad idea. So we switched back. And not every problem is a nail. So just because we all love microservices, we cannot use them everywhere. It's not the solution for everything. You really have to analyze whether it's the right thing for you or not. So let's containerize one of the open source applications. So I picked up the FreeCodeCamp on GitHub. It's an open source heaven for the current century. And what FreeCodeCamp is, it's a free website which helps developers to learn JavaScript programming. And the technologies used to build this software is Node.js and MongoDB. So here are some of the steps used by FreeCodeCamp to run the software. So what you have to do is you have to install all the dependencies. You have to install Node.js. You have to install NPM. You have to install Bower and all the stuff. You have to run through the different setup steps to be able to run this application. So here, what's happening is when you have all these dependency steps, they're not the same for different environments. If you are running it on the Dev machine, if it's on your Mac, that's different. When you are pushing it out to protection, you could be using different operating systems. So it's not a deterministic way. The other thing that we are doing is we are polluting the host. Like you are installing all the dependencies onto the same host. So if one of the package needs an upgrade, it could potentially break other components. To have an analogy of the FreeCodeCamp application is you could think of it like the bedroom is the web application. And you could think of the database and the library as something that is not something that you are interested to scale. The application is what I am interested in scaling. So how do we break this apart? So the first thing is, remember the low hanging fruit? That's the first step you can do to containerize or move your monolithic stuff into microservices architecture. So two of the big pieces that I can see in this application are the database and the Node.js application. So I would like to repackage them separately and run them as different containers. So I had a few slides explaining about what the Docker file of MongoDB is doing, what the Docker file of Node.js is doing, how do you build and things like that. So this is the source code of FreeCodeCamp application. So here what I did is I introduced a new Docker file and here we are using the Node.js existing image and building on top of it. So I'm moving the source code of the FreeCodeCamp inside the container and I'm running the scripts inside them so that I could start them. So this is an example of the Docker file that I used for this and the different lines in this Docker file are going to end up as different layers in the Docker image. Let me just build this. So I have a script which does the building of the Docker image so here you can see I am building an image on my local laptop and I think I'm having some networking issues. Okay, so I'm not sure, I cannot debug it right now. So what I wanted to show here was I wanted to build the FreeCodeCamp application as two different containers on my laptop and then take these two images, push them to the Docker hub and then use the same images to run on two different servers in the cloud and one of them servers which I had set up was running Ubuntu operating system and the other one was running Red Hat operating system. So I wanted to start this application in the cloud to show you that the same image for the containers that we have built locally is the same thing that we are running in the cloud. And it's the same environment in development as well as in protection. That was my intention with this containerizing the FreeCodeCamp application and running it, pretty much it. Thank you, thank you for joining. If you have any questions, I think he has a question. If you were trying to work with developers to have them containerize their own applications, like what advice or guidance would you give them? I couldn't hear you, could you please repeat? If you were working with developers to help them understand containerization and to guide them, what advice or policies would you give them? So some of the, so the question is, what advice would I give to developers who are trying to containerize applications? The first thing that I would tell developers is like, you know, when you're trying to containerize something, you would want to use something existing, you know, something, try to leverage what is already existing. So let's say you want to package your Node.js application, instead of trying to build from scratch, you could use Node.js image. That's one of the things. And the other things is like knowing the details of what the different Docker commands do. That's the second thing that I can tell. And the other thing that I have learned running containers and building images is if you have multiple microservices trying to run on the same host, you would be able to save some time by using the same base image. So these are like some of the tips I could give for developers. There's another question. So I was curious, when you first start moving from like a monolithic application to containers, how did you tackle the service discovery at that initial step? So in our product, we built our own service discovery. So we have our own small little microservice which provides the DNA service within the cluster. So if you are using different technologies like probably Kubernetes or Docker's form, they have some solutions to provide service discovery. I had a few questions regarding microservices. And one of the first one is at which point do you think microservice, lik