 The title out there is about Docker, and that turned out to be a lie. I've rewritten this talk about 10 times. Each time it gets better. This is the 11th time, so I'm sure that trend does not continue, and this will be much worse than the last time I rewrote it. So I apologize if it's awful. The way this will work is I've kind of broken it into five or six sections, and each section will have a little Q and A afterwards. So instead of me rambling for 30 or 40 minutes, you'll hear me ramble for five minutes, and then you'll hear me ramble about a question that one of you asks, or two of you ask. I do not, well, I do have a timer. Let me make sure I've got that set up so I'm not going over time. Let me remember how to set up my timer. Dude, dude. I swear, phones and printers are my nemesis. They are the two pieces of technology that I will never understand. Do not turn off. Autolock never. There we go. Timer. All right, now I've got a timer. So anyway, this talk will be about Agile infrastructure, and in order for us to begin this talk, we have to answer a question. What is Agile? Most of you are Agile practitioners, I'm assuming. You have been doing Agile work in your businesses, or been reading about Agile, or been applying Agile principles, and you've probably all gotten very familiar with the Agile manifesto, which is the core of all Agile practices. I have a few problems with the Agile manifesto, and so I've rewritten it for you today, and you can feel free to throw things at me if you hate it. Make sure it's not hard things, by the way, if you do throw anything at me. So the Agile manifesto in my mind is very confrontational, which was important. 15, wow, that long. 16 years, 20, I don't know. Back a long, long time ago in the dark ages before there was light, and I think that we need to reframe it a little bit if we are going to embrace Agile now, where we're not quite in the same space. So instead of just individuals and interactions over processes and tools, it's individuals and interactions supported by processes and tools. Any process or tool we have should be in support of the individuals that are part of the team, are part of the organization, and facilitating positive interactions between them, which is, again, it's not unheard of. This is kind of what the Agile manifesto meant, but because everything was so process heavy back then, it had to be very, like, gr. No, processes and tools are bad, which is, I don't believe the case anymore. Working software supported by useful and valuable documentation.