 Hi again, Red Hat Developers. This is Jason from the Red Hat Developers program back at Summit in 2017 in the Dev Zone. Today we have Scott McCarty, who's going to talk to us about achieving DevOps with containers. He's going to show us three things that people miss. So when you're trying to achieve DevOps, a lot of people, you've got to get back to the basics of what their actual problem that you're trying to achieve is or solve is. Developers in operations essentially have to deliver applications quicker. And the applications are more complicated. And they have to collaborate because there are complex interactions between the operations environment and the applications that you're delivering. And historically, those have been married in the user space of the operating system. And it was a collaboration that would happen when you first deployed the app and a collaboration that would have to happen down the road time after time every time you patched the operating system. And so the fact that these are complex is kind of the problem. And so we've tried all these different tools to try to solve that, including configuration management and change control tools and things like that. So the question is, how can containers help, right? Well, number one, what do people miss? So load applications at the factory. Don't do it at the dock. Historically, if you look at a cloud environment, it's like being on the dock and there's a bunch of ships in the harbor. And you're loading the ships with these applications with something like configuration management tools or static images that you've built. And you don't want to wait until you're at the dock to think about things. You want to do it at the factory. You want to think about all the components. And you don't want to have political battles when you're trying to do something live in production. You want to think about those ahead of time during business hours. And that's what containers help you do. You get to build all of it and collaborate on all of those things that you're going to make in dev, not in production. And so you want to think about what components like trusted sources, like pulling Red Hat container images from the Red Hat container catalog, using Ansible to do declarative ways of building the images and things like that. And you really want to wait until you don't want to wait until you're in production to think about that stuff. You want to do that in dev at the factory. The next thing is collaboration, right? So there's a lot of components that go into a container image. And just because you are now doing that at the factory doesn't mean that you don't have to think about those things. They don't just magically disappear. You still want to build on standardized images, just like you did before when you had core builds. You want to agree on a single definition for the application, so you want to use something like Kubernetes or OpenShift templates to actually define the links between the applications. And then you still want to collaborate in a way that's organized. So there are certain libraries in the container image that you don't really want to have to deal with as a developer. You want to offload those five minutes after that goes into production. You don't want to have to touch it. So things like OpenSSL and Gigalib C and NSS, you don't have to patch those. And then finally, when something breaks and it's finicky and it's in production, you don't want to get paged at 2 AM. So you just want to build off of what they have, let operations collaborate with them ahead of time, build at the factory, and then collaborate on what's inside of it. And then finally, this idea that microservices make it easier is not exactly correct. It actually makes things wildly more complicated in that you've got now tons of copies of these apps running everywhere, and all the apps are broken into all these little discrete chunks. And so making a small change to a chunk is OK. But what happens when you patch a library across an entire cluster in 32 different services? It gets very complicated. So you really have to think in a distributed systems kind of way. So when you're doing that collaboration at the factory with developers at SysEdmins, you want to think in a distributed systems kind of way. You want to think about how can I automatically rebuild these things? How can I automatically schedule even tools to go out and troubleshoot things at scale, essentially. And you want to test the exact same, for example, since you've standardized on a Kubernetes file as the template for your application. That's what tells all the containers to talk to each other, and how. You want to test that ahead of time in Dev also. You don't want to just build the app as separate pieces, then in production, run it that way. Because you'll end up running into problems that you didn't foresee. There will be race conditions and things that you didn't foresee. So you want to really test that entire stack with the exact application definition and the exact images that you used in Dev. And you want to do that ahead of time, right, at the factory in a collaborative way. So I mean, at the end of the day, what do you get? You get your app to production faster, because you've already solved all these political battles and all these collaboration issues, and you've already decided on what all the components are ahead of time. You've decided how the components interact by using the Kubernetes file or OpenShift template. And at the end of the day, you want to be able to move on to the next project. You know that once you have those developed, and once you have the blueprint for how those components interact, done, and you've got testing around the images and the blueprint, you can now move on to whatever the new project is. And then finally, when you're troubleshooting it two years down the road, you have compatibility at scale. You don't have to worry about saying, hey, developer, you don't want to get paid at 2 AM when you're working on some new project and you have a deadline. At the end of the day, you want the sysadmins to be able to handle that. And so those are the three things that I think people miss when they really start to build applications and containers. So thank you.