 So for those of you that don't know, my name is Charles Butler. I work for Canonical to find people behind Ubuntu Linux. And I'm gonna talk to you today about the magic of application modeling. This is gonna mean something slightly different to everybody here in the room because this is not a tool talk. This is a principle talk. And I'm gonna be using some examples from my day job. This is not a sales pitch. So let me just lead with that because I think that that was a great call out earlier today, whoever did that. But in the beginning applications were simple. We had a couple servers, you know, you could probably manage it in a weekend standing up your deployments manually. But that's not nearly the case anymore. And I long for these days. I wish I could go back to just managing two servers, but that's not at all where we're at. So we see that we're starting to co-locate things and density deployments are becoming a thing. And there's also this interesting container technology. Maybe you've heard of it, LexD, Docker, all those orchestrator managers. And what this means to you is that density is going to be a thing. We're going to have a lot more inputs and outputs to our applications. There's a lot more to manage, a lot more to think about scale. How do you actually talk to that? Maybe you only have one reverse proxy. What happens when that one reverse proxy goes down? All of these different things tied together to make up a cohesive application ecosystem. And it's very, very hard to get that information to transfer between people if you're not representing it in a way that's human consumable in format. So the phase change has happened. Whether you're ready for it or not, it's all here. This is a model application of a typical startup with a lot of web apps. We've got some MongoDBs, some Rails apps, some big data stuff over here. And whenever you look at that from a machine view, it gets even more complicated. Where was all this placed? Why was it placed there? I have 200 of these nodes with all these applications that now have credentials, that have routing concerns, that have policy concerns, all of that stuff. How can we operate this big software sanely so that way we're not spending all of our day in our data center and trying to communicate to other people how this works? So the model becomes the golden ticket because models are logical representations of our applications. It's how we represent inputs and outputs. We can see here by this model that it's a very simple MediaWiki installation. It's using two MySQL databases. It's connected to a Memcache database with an HA proxy, reverse proxy. I think that everybody in this room can see that what's talking to what? We see that MediaWiki is talking to this particular MySQL database, not this one. And these insights become super important. But we can take this a step further. We can even start baking in the operations into these models. And what's super nice about that is that then anybody that uses these models gets that operational knowledge. It's no longer siloed in one department or even in one business. Maybe you can use this with cross sectors in your business. And by doing this, we can start to look at the six tenets of what I'm calling open source operations. We take a look at how it scales, how we would back it up, what our deployments look like, lifecycle management, durable storage, tuning and operations. And what actually enables this is the relationships between applications. And this is what's the most interesting part to me. In this particular example, you're seeing an exchange of TLS certificates between an Apache web server and TLS database. So let's take a case study of how canonical came to me and they approached me and said, hey, there's this hot new technology called Kubernetes. I want you to model this. And I want you to give this away to everybody so that way they can stand up Kubernetes easily. Cause at the time, 1.0 wasn't even a thing. There was some shell scripts that you had to run. And so, okay, I had just gotten started with Docker and my first iteration, totally not representative of what Kubernetes is. I started with Docker being the primary, the legend that's missing here is that there's, these two smaller circles are subordinates. They depend on this first thing. So in order to scale it, we had to add a unit to Docker and that's not intuitive at all. So we took a step back, iterated on this model and our second model came out as overly simplistic. There's one Kubernetes application and one at CD, which is the database. It's not clear to anybody what the SDN is, where your TLS is coming from, how would you separate your control plane and your worker nodes? So that's where the third iteration came in. And now we can start to get to the point to where we can interchange some of these components because these components know how to talk to one another. And that's where it really gets interesting. Cause as I said, relationships become the most interesting part and you can now start to mutate this model and you can model that operational activity with no pictures. So as you go back to into your workplace, I challenge you to start thinking about how you would model your operations, how you're going to distribute that information to other people in your organization. And if you're super curious about how we're doing it, you can come check us out at juju, just Google jujucharms.com. And that's all I got. All right.