 I'm local, I like to snowboard, and I have a 60 pound dog, he likes to cuddle, and I work on a team with AT&T that makes software that does operations stuff. Today I wanna talk about using production service definitions on the laptops that you use to iterate on those services. You see, in the software development lifecycle, we often have a lot of drift between our development and prod environments. They kinda look a little bit like this, you know? So you engineer these crystalline structures with your development teams, and then you expect that Ops is able to just like lift it across buildings while thousands of users are watching, you know? And I think that the reason why we get into this problem is that we have a mindset issue when we're engineering. We build things on one computer usually, but when we get into a data center, there's lots of them. Now, I think a good solution in this problem is to learn from our friends, use a service platform. What these things do is, I mean, they're operating systems, they let you treat many computers as one blob of classified compute. And when you commit to these service platforms, you start writing stuff like this, where you're declaring the desired state for multiple services to interact with each other. And now you have these uniform environments, these things work basically as well as they do in prod, as they do on laptops. And now you start scaling these services out, you're dependent on so many different more kinds of configuration, you're using three different kinds of S3 bucket. How do you develop for that? You see, without bringing the data center onto the environment where you're iterating on services, it's hard to empathize with that problem. And normally we'd use something like virtualization to accomplish this, but I'm a developer and I like tight feedback loops, so we're gonna use Docker containers instead. Containers are good at namespacing processes, which means that you can run your platforms and schedule containers to containers. There should be an example popping up of this. This is a visualization that's actually running on a laptop. And those five containers there, well there's actually four of them, one's the host, they're running a Docker swarm that schedules the actual services that I'm working on to the cluster that is running on my machine. And you can see how this is something that's at my fingertips. I mutate this and I can see what happens. I can see the failures. I can see how what I'm doing schedules out across imaginary infrastructure so that what I'm doing scales into production. And I have a repository that has some code, some documentation, some examples of how to get started with this kind of workflow. Would love more comments and that kind of thing. This isn't the only way to do it, but it's a good way is what I've found. And yeah, really why do you wanna do this? Ultimately, you're reducing the drift to nothing. You're starting out in your iteration environments with what you want in production. And that gets you all of the superpowers that you expect from a modern data center. The tests, conformance, smoke tests, integration tests with other services that run in your prod data centers, those things, they can run on your laptops. Your laptops are powerful enough. Your auth service is not that complicated. When an issue happens, hey, GitLab, thanks for talking about that. You can take that post-mortem and take that state that's described, model it in your lab and write conformance tests to make the system better. Ultimately, what we're really getting at is that when we make services, they're not coupled to infrastructure. That's a bad pattern. Our services are coupled to compute and the kinds of classifications and capabilities that that compute gives us, that the compute enables the service. That's what we want to couple to when we say that we build cloud-native software. Ultimately, there's one thing I wanna advocate in this talk. It's that these days there's too much knowledge in tooling and distributed systems to be treating your data center like multiple computers. Commit to a service platform. For any new work you're doing, there's no reason to disobey this pattern. And ultimately, use those superpowers on your development machines. You're gonna be able to iterate so much more confidently and quickly. You test and iterate on your software with the same tools that gate your deployments. And it's a good way to build things. So, ultimately, my name's Lee again. Please reach out to me, that's my Twitter account. Let me know what you like and share ideas. I really wanna meet everyone, so thank you.