 Next up, giving us our afternoon keynote on the state of the container ecosystem is Google's Kelsey Hightower. Uh, okay. So this is going to be a very weird talk for me because I won't be doing any live demos. So I'm like going to fish out of water right now. And, you don't see my laptop? You got to make it work. The pressure's on. They're all looking at you. Because this is not going to be my fault. It's your fault. It doesn't work. That's how it works. What do we got? We mirrored? Arrangements. Does Red Hat like penalizing me for not using Linux? Can we just tune the projector for Linux this time? All right. How about that? Bam. All right. Here we go. I'm good. See, I fixed it. And he ducked that from someone's check over there. All right. So we're going to be talking about the state of the container ecosystem. Is there a clicker thing? No clickers? We don't need a clicker. What if my talk was titled the state of the virtual machine ecosystem? You guys look at me like I'm crazy. Like why would you even talk about virtual machines right now? Right? Because no one sees value in the individual virtual machine. The value that you derive out of virtual machine usually comes from some platform or cloud provider, OpenStack or VMware. No one thinks about a virtual machine. Yet we're talking about the container ecosystem. And that's equally as crazy. What are you going to do with just the container? So the thing I want you to think about as we talk about this stuff is, in my opinion, virtual machines are to cloud what containers are to platform. Why do we want to adopt containers? It has to be a reason. It can't just be going from one application distribution platform to another. We need a reason why we're doing these things. So containers to me are definitely not the most interesting thing to be talking about. At best it's the implementation detail. It happens to be the thing that we've chosen to agree on today for sharing applications with the various platforms that we want to run on. And this to me is the biggest source of confusion because some people are saying I'm moving out of the cloud and I'm moving to containers. I'm like, whoa, that's going to be fun. So we can't talk about an ecosystem without metrics. How many people like the metrics when analysts show them? How many people believe the metrics? You can't believe the metrics because no one knows where they came from. I surveyed my family and they all like me. It doesn't mean anything. So I want to show some metrics. And these metrics, you must trust me, are 100% accurate. All right? You have to trust me or they won't work. Here we go. Some percentage of organizations want to use containers. Anyone here want to use containers? Boom, one. You raise your hand. Leave it up. Don't be trying to flash it right there. Automatically true. Doesn't matter how small the percentage is. This is also true. Some percentage of organizations are using containers. Brandon, are you still in here? At least Brandon Phillips from CoroS. If you work at Red Hat, you're probably using containers. If not, boy, you're selling snake oil. Right? So this is also true. But this is the metric that is probably the most true. Some percentage of organizations are waiting to use containers after some percentage of organizations start using them first. Successful is not a requirement, actually. All you need to do is write a blog post or appear at a conference. That is enough to be trustworthy. Like on a play, we'll come back to work and say, hey, here's this blog post saying that this works. I'm not sure what you're doing. Right? And this is the state of things. Honestly, this is the state of the what people are thinking about. So when we start to have this conversation, no one is really addressing this particular thing. What is it going to take to move that percentage number of people using containers to get the other people off the sidelines? Right? This happened to virtualization. Remember people like, we'll adopt virtualization in five years. And then the cloud came and said, oh, that's different than being where we set the clock. We'll do cloud in five years once and up. Oh, there's this container thing. We'll do containers and so it's nonstop. Right? So we need to figure this out, this formula. This is the thing that's the most important thing to figure out if you really want to understand the state of things. So we are going to talk about containers because we need to understand and have the right vocabulary and terminology to talk to each other and people that are interested in the technology. We cannot keep waving our hands about what containers are. If you're in the process of developing a container strategy, stop. You don't really need one. You need to figure something out that's much broader, much bigger than just putting your app in a different tarball. How many people know that the jar file is like a zip file? Right? You blew your mind like, no, just unzip it. It's like unzip jar and things came out of it. Same thing happened with containers. You go get one from the doctor and say, oh, that's a doctor image. Man, that is like dark magic on tar. But we need to all be educated on these things. So here's the harsh reality for some people. Doctor is the de facto standard container runtime and image format for Linux and Windows for most people. And we ask ourselves, why? Why do they hold this dominance over this idea of application containers? We're not talking about all types of containers. We're talking about application containers. And number one is they nailed the developer experience. People attempt to come in and compete with Docker and where do they fail? You try their solution, you get on your laptop, it doesn't work. Done. Go back to what you were using. So if you want to understand what the de facto standard is, it's Docker because they give you all the tools to do it end to end. Is it perfect? Not really. Not all the way. They've done a lot of things well and the parts where it isn't perfect, that's where you see the opportunity. So if you want to understand the container ecosystem, find out what Docker doesn't do well. And that's where you see the new company spring up. They spring up to fill in the gaps of where people are filling pain with Docker and it's very strategic. Everyone isn't rushing out to build a new container runtime. That's pretty decent. A lot of people aren't running out to build a build system for container images. That's pretty decent. But the things you do in production around containers, so that's not a solved problem. So that's where the innovation for containers come from. So if you want to pay attention to the trends, you don't need to wait for the news outlets. Just go and use Docker and figure out where it's weak. That's where you see the next things come from. It's a very simple formula. There are other container runtimes. Most people forget this. Rocket is a really, really great container runtime and it actually came out in a way that addresses the concern that most people need when you decide to adopt a platform on top of the container runtime because you need less from the runtime. You don't desire to interact with the runtime directly anymore. So in that case, you're like, well, I just need something that can simply download and execute my application. I do not need a entire workflow for my production use case. So we have things like Rocket. How many people know what CRI-O is? You work at Red Hat? Okay. So this is a runtime implementation of a lot of the work that's going on in the open container initiative, OCI, to build a container runtime that implements the Kubernetes container interface. So in the Kubernetes world, we act like Switzerland. We're neutral ground. We say, you know what, Docker, Rocket, it doesn't matter. It's never going to end based on experience. Everyone's going to have a reason why they need the container runtime that they need. So you know what we're going to do? We're going to make most of the logic that Kubernetes needs. We're just going to bake it right in Kubernetes where it lives today. And we're going to make a well-defined contract to say, hey, if you have a container runtime, you implement this small interface however you want to do it, you'll be compatible with Kubernetes. That's it. We're done. We're not going to play favorites. There's no need to play favorites. Because in the case of CoreOS, Rocket might be the best container runtime for you to be well integrated into the OS. It may have other things that you need. No worries. Kubernetes will be there for that. And in other operating systems, we'll just have other ways of doing things that are native to that kernel that you may not be able to port a runtime to. So it just makes sense to take this into consideration. Some people are actually waiting for these container runtimes to consolidate. People actually believe that there will be one container runtime that will actually win and dominate. It never is going to happen. If you were waiting on that, if that was part of your container initiative, you should stop, but it's never going to happen because it can't. No single container runtime will be willing to do all the work necessary to deeply integrate to every kernel that's out there that provides this kind of capability. So I think it will continue to expand as new platforms or hardware devices come out. You're probably going to see things that are built to be platform specific. But this won't be a problem because you should be designed to higher level APIs. These low-level details, that's not what you should build your whole company on top of. You need to go a little higher. But we are going to come out with some things that will give good reference and starting points, like the image spec, even though the runtimes may be diverse, but we can all move around these root file systems with our applications deeply packed. That makes total sense. There's no reason to try to come out and redefine your own image format. So we have the image spec. And the image spec is taken from Docker v2. It's popular. It works. It's pretty well-defined. There's multiple implementations of being able to pull it and run them. So we start there. And the container runtime spec will attempt to write down the things that we're already doing in the way that they can be implemented by other people. So we're making good progress. And we're starting to share the knowledge and understand this. So if you want more details, check out the work that's going there. And I think both of those specs are reaching 1.0 fairly quickly here. And I think you're going to see this kind of be the standard that most people that want to participate in these communities will adopt. But containers only get us to the point where we start to realize that it's about the application. The containers that we're talking about today and this week, we're talking about application containers. There are system containers where you mimic a whole OS. You do the whole boot process. And the goal there is to give you this lightweight virtual machine. We're talking about application containers. So application containers are just hopefully that we'll get rid of this deployment process, how we package, how we get it on the box, like moving bits on this. That is so solved problem. I can't believe we're still spending this much time trying to figure out how to get an app on a server. What the hell are we doing? This to me is really sad that in tech we spend this much time trying to reinvent the wheel at every organization because we believe that we're so special. Not really. I think mobile did a great job. Imagine if we try to port all of our tools to mobile. Imagine using like Puppet or Chef or Ansible on your mobile phone to install an app. Battery life, just whoop. It makes sense. So these are some of the real things you need to actually worry about. Once you actually get successful containers, this is the next set of questions. Hey, it turns out everyone can log into the app. That is a bad idea. No logging, performance, API compatibility. This is the biggest one. People are just like, man, we got this continuous pipeline. We just roll changes. And all the other teams are like, I hate that team. They don't even understand API compatibility. It breaks every 10 minutes. That stuff is important and containers don't address this. Hopefully they allow you to focus on it. These are the other things like data locality. So some of these platforms allow us to figure out how to get our data or application closer to the data. And people are like, oh, why would you want to do that? Everyone believes that you own all the data. Some people do not produce the data that they need to compute on. So you have no choice but to move the compute to where the data is. That's the new world. And in that world, you're going to need a system that knows how to do that, or you're going to be manually doing that. So containers allow us to focus on some of these harder problems. And for some unique people in the room, you actually have customers that generate revenue. What's the point of shipping your app in a container if you have no customers? You should stop that immediately. You should abandon ship on all initiatives until you find a customer, even if it's an employee that works there. Give them a credit card and buy their product until you can do that. These are your real problems that you have to deal with. Everything else is almost an implementation detail. So we need a platform to help us manage those things. So in the container ecosystem, we stop talking about containers so much. I've actually, in the last year, don't really think about containers. I look at them as a necessary evil in order to use the platform of my choice. I'm no longer excited about the container. I look at the container. Damn, I've got to put this in the container? Like I'm ready to go, but now I've got to put in this container. I've got this intermediate step. So we're seeing these platforms attempt to address the application problems that we have. So we're going to talk about the state of application management solutions. So one thing we need to be clear on, containers do have value, right? We stopped talking about Python versus Ruby versus Jar for our versus war ear. Man, the enterprise got screwed over on that one, right? Jar, war and ear files. Which one do you use and why? I don't know. So containers now become this common unit of compute that we can move across these three primary things. And I want to make sure we understand the difference between these three things. And I think this is the source of confusion where we are now. We're seeing these application management platforms come out and we're not sure what we're being offered. So I have these three categories, and these are just all my opinions if you haven't noticed, by the way. Frameworks, container as a service. How many people have heard of CAS? People just like saying these things. Anything with AS on it, it's CAS. And then platform as a service. Now, no one wants to be called a PAS anymore. It's a very dirty word. PAS has failed in one big regard. They had too many opinions. And when they ship those opinions, there was no way to back out of them. It was all or nothing. Either you're all in or you're out. And most of them didn't provide any APIs for you to build anything on the side and still have some first class access to the rest of the PAS and all the features it provided. So we're going to have a redo. So application management frameworks. These are application management frameworks. Kubernetes, which is being steward and governed by the CNCF. So it started out as a Google project, but it's now a much bigger project, much involvement, especially by companies like Red Hat, CoreOS, and a slew of others. We have Mesos, which is one of the more maybe mature and been out there for a while application management frameworks. People build other things on top, the whole two-part scheduler deal. Then we have Nomad from Hashicorp, kind of a new up and comer. And Swarmkit from Docker. Swarmkit is probably the newest of the field. It's this idea that we want to provide things that have APIs that really focus on the application. So you start to see these things shipped with things like in the case of Swarm, they have this app bundle, right? They're talking about app bundles and not container bundles because now you're starting to address the application itself. And the same is true for the rest of those things. Application frameworks tend to get mature and then they're offered as a service. So this is where you package up these open source projects and you add enough glue code to make them work well in a specific environment, right? So when you go to Google's cloud, if you want to use Kubernetes, you will use GKE. In Amazon, they will package up maybe Docker and other container technologies and have something like ECS. And the goal here with these container services is that they do all the heavy lifting to make sure that they work well in your target environment. I think with other tools like OpenShift, they'll bring that to your own data centers, right? So we're starting to see these not just be regulated to something hosted by some provider, but they'll also be available for you to install on your own. But remember, I think the CAS is different from a framework because the CAS is usually tightly integrated into the platform where you're actually targeting your application. That's the big difference between the frameworks and the CAS. So a lot of people are confused because they go and download the framework and find out they have a lot of work to do to integrate it well into their own environments, and they're looking for something like this. And the last phase is this application management platform, the platform as a service. So this is where all of the opinions come in, right? In the Heroku world, you're going to build a 12-factor application, which means you're not going to be able to store any data from your app. You're going to take your configuration through environment variables. These are our opinions, and if you're willing to abide by our opinions, then you get to run in Heroku, and you get to inherit all the things that come with that. Then in Cloud Foundry, how many people here are making that digital transformation, right? That's the mantra that they have because in order to adopt Cloud Foundry, you need to re-architect your app in a way that will work based on the opinions from Cloud Foundry. And it's not that they're bad opinions, but they are opinions and they're strong, meaning if you don't conform, you're going to have a bad time. If you do, life gets really fantastic. There are a lot of successful larger companies. Snapchat is one of them that use App Engine, and so you know what, those opinions work for us, and we're just going to only focus on our business, not deal with infrastructure. But then you get this new hybrid thing, OpenShift, right? OpenShift v3 says, hey, people want this hybrid model of, we still want the strong opinions. I have some developers and some people in the staff. They just want to shift the application. Get build, get check-in, get push. My application is built, who cares about this container thing? It's up and running and we'll take the opinions, and usually the opinions are based on best practices. People aren't just making these opinions up. Usually this is like from time we say, this is probably the best way of doing it based on what we know, and that's what you get. But this hybrid model is like, what if you want to do something that it doesn't support? Well, the container framework is still underneath there. You still can actually go behind it and create your objects natively in the framework that is built on top of. And I think this pattern will hold because this gives the vendor a lot of leeway in figuring out what the actual best patterns are that should make its way into the default opinion set, but still allowing customers to break out and do things that they don't necessarily have offered in the platform of itself. But platforms are not the end game. How many people believe that the platform is not an end game? It's okay to disagree with me. You guys can't get us to set it up wrong. You're like, no, I can't disagree with them. It's going to call me out because I know that next slide is going to kill me. Maybe. But honestly, this world attempts to, you know, with some application changes, you can adopt these platforms, but we do so much work to support the lift and shift. How many people have heard of the lift and shift? How many people are actually doing that right now? It doesn't work out well at all. You can get everybody's like, oh, it's working, and then sec fault. So what the hell was that? It doesn't work. So you've got to do something else. I think the app has to actually get intelligent. No one wants to hear this. You are going to have to write some new code to take full advantage of these platforms. That's the reality. And I think we're getting closer to that. So the new state of things is now it's back on you, the application developer. You're going to have to do something. So this is what's now the trajectory that we're seeing, whether it's serverless or whatever you want to call it. But a lot of times is what's happening either we're reducing the interface that you have to implement or your application will need to be smarter. And here's a set of libraries that help your application be a bit smarter. So if you haven't heard of these libraries like Spring Boot or Spring Boot route, this should be Spring Boot, LinkerD, GRPC, and GoKit, all of these attempt to bring things like service discovery, client-side load balancing, metrics, monitoring, all those things closer to your app. So your app can actually leverage the benefits that you get from some of these platforms that you're running now. So to solve it all up, containers only solve a small part of the problem while creating new ones. It's not a free lunch here. And at the end of the day, when you start to think about the container ecosystem, you have to focus on the application. And I think that will give you the tell signs that you need. Thank you. Great. You all believe what I'm saying except for this guy. I'll start here. Yeah. So all right. If you didn't see your favorite runtime on the slide, so the question was LXD, I didn't see it on the slide. If you didn't see your favorite runtime or project on the slide, I only had four lines, right? And they were sorting in alphabetical order and there were no logos there. I have gotten an email before. It's like, hey, my logo was smaller than the other logo. But there's nothing wrong with LXD. I think all of those things are to me, though, they're going to be implementation details because most people at the very high levels when you're using these application management platform, you can care less of it as LXD, LXC, Docker, or Rocket, because this is the level that you want to operate at. If you find yourself weighed down here, then you're either A, building your own platform, which most people are in the habit of doing, but they don't know that they're doing it. So as long as you're aware that you're building your own platform and if you're successful and if you're lucky, you'll end up with something that looks like open ship in a few years, all right? No, it's serious. It's like either you're buying one or you're building one. There's nothing wrong with that. You just need to know what you're doing here. All right, so the question was, one benefit of the PAS was the developer workflow. And I think what we're really saying there is that the PAS had an opinion on how that work show should be. Like, you go to Heroka, it's like, nope, get push. We're not going to have meetings. We're not going to talk about this. It's not going to be an initiative. Get push. And a lot of times, the reason why you're successful is because of the options. Any time you take away the options and introduce constraints, people have to make a decision. Most people are just paralyzed because they can't make a decision. There's too many options. Do I do Chef? Do I do Puppet? Should I write some Bash? Should I use this thing? So I think the PAS is give people an opinion. And then when you accept the opinion, you get all these benefits in return. Lower down the level, I think, in the case of Kubernetes as an application framework, we do introduce more opinions about how to get people vested. SSH into a machine, almost zero opinions about how to do things. In Kubernetes, we say, it has to be in a container. So the developer workflow at that point is really influenced by that one opinion about Kubernetes. You need to figure out how to get your application into a container, into a registry that can be pulled. So then that starts to shape the workflow. Maybe it's Docker for mackling your local machine. But ideally, we should probably even move away from that in some cases. Like CICD is here for a reason. So let's push those things into those. And let that be abstracted away from you. So whether you're using a PAS or application framework, the developer experience should be the same. Write some code, run some tests, and check it in. This whole laptop equals production business that needs to stop. Like, that's... Vagrant, like, cost us five years. As much as I love Vagrant. But most people lost their minds. Like, oh, I can just put production on my laptop. It's like, no, you cannot. You have one gig of data on your laptop. There's 20 petabytes in production. You've got to index every column. It doesn't work that way. Okay? So I think that workflow needs to be unified. But yes, you're right. PAS is bringing a very well-defined set of opinions around how you should get application code running in the platform. Any other questions? So you've been talking about these opinions that basically, if you write your own software, you want to implement these... use some of these opinions. What about for IT and operations groups that are primarily running vendor software? So I can't go and tell Atlassian to make Jira follow these opinions. I just have to sort of take what I'm given. What I'm curious is where you see the breakdown in terms of how much of that is on the vendors to fit into these new platforms versus to what extent the weight is on those platforms to work with the way that the software is already packaged. How backwards compatible to the old world should those platforms be? Right. So the question is that a lot of times in IT, it's not about the apps that we write. We have more control over those. It's about the software like Jira, God forbid Oracle. You're bringing these things in and you have to do what the vendor tells you. Okay? And we have opinions about those vendors. They're not very favorable right now, especially given the fact that new software that comes out, you're almost entering into a partnership with the vendor versus them telling this is all we're going to do, just deal with it. Now there's just so many choices in these areas that I think from the perspective now is that that's changing. When you talk about older software, I think with older software, if I can keep making the same money from you with no changes, why would I change it? Right? So you do have some. Stop paying the money. And if you're in a situation where you're stuck, I'm going to be honest with you, you're screwed. Like seriously, people come in and say, no, we can build stuff around the app. It will make it work and all these things. You know? I think most people can put some band-aids on it, but you need to figure out how long is it worth. And sometimes, you know what's okay? Just run it over here on the legacy hardware. I don't understand why everyone sees something new and wants to push everything into it. There's just no reason for that. Honestly, in practicality, you should just run the things where it makes sense. So if you have some legacy software and you've figured out how to get it running in those environments, leave it there. Ignore the noise over here and just do what's right for that particular application. When are you writing your next book? When does the book come out? Ah. So my book has been labeled as the Duke Nukem of books. And a couple of things, and it's probably good news, oh, I can't share. So I have some new co-authors. When you see their names, you're gonna be really happy who they are. Okay? So the book is about 60% complete, but my co-authors will bring, I think, some originating opinions about Kubernetes. That's the only hints I will give you. Okay? So the goal is the book right now has a lot of detail on exactly how to do things in Kubernetes, but what I'm thinking is missing from the book is the why. All right? What at Google led people to believe that the complexity of using distributed systems to do things like manage applications was worth it. In order to tell that story, I needed more voices that had that experience because I have a lot of practical experience with Kubernetes and the outside world, but we need that voice to fill out the book and that's what's going to happen. And once I get legal permission from all of those entities, you will know. All right? Thank you all so much.