 I didn't hear a bad joke, so I'm going to make some of my own. All right, so let's talk about choosing your own abstraction, specifically iterating on developer experience. I'm Rosemary Wong. I'm a former platform engineer. Now I talk to a lot of platform engineers and developers trying to find the right kinds of interfaces for a platform. In recent years, we've really focused on the right platform interface. This turns out to be really complicated. It's a long discussion that ends up across like two weeks, three weeks. At one point, I think it took four months for me to work with a team to find the right platform interface. And eventually, the first iteration of a platform tends to be infrastructure as code. So you'll choose some kind of tool that creates your infrastructure as code somewhere, and now everybody has to learn it. But then you hear this terrible statement that makes your blood curdle, I don't want to learn it. And it's a fair statement. Sometimes, as developers, you don't really want to be learning a different domain-specific language, or you don't want to be learning a different programming language that you're using to create infrastructure or platform resources. And it turns out that, well, we have a solution for that. In years past, we've used the UI or CLI approach just to make it better. So this could be the form of a service catalog. This could be a form of any UI or CLI. And the idea is that you can onboard your developers to the platform. This comes at a price, though. The higher level your interface, the more standardization you get, but you don't get the customization. So if you have certain use cases that can't use a UI or CLI, or have some specific needs, you still have to learn some infrastructure as code. However, you still get to handle the 80% of use cases that someone's going to use to provision a platform. And so that's where Backstage comes in. Most folks now are looking at some kind of UI CLI that provisions a set of templates somewhere, a GitHub repository, all of the components you need. And if you want to bundle a database with it, you can provision the database using infrastructure as code and a bunch of templates. But what about updates? This is the place where everything sort of falls apart. No matter how many times I've helped folks build a platform, we always forget about updating the platform for some reason. And it turns out the right platform interface has to account for updates as well. And that's where now we've thought about GitOps, right? The idea that we can continuously deliver any changes to our platform with some kind of declaration or manifest using some Kubernetes interface. And this kind of makes it easy because you can make changes with a familiar interface. If your developer knows Kubernetes or some kind of Kubernetes interface, they can make changes through the GitOps mechanism. So any framework you use will continuously deploy those changes, reconcile, and see if there are differences or drift, right? And GitOps has become this middle ground for the right platform interface because now you get the customization and standardization, but then now there's a common interface for developers and platform to understand. And so in this case, maybe I'll show something like RGOCD, but in any GitOps framework that you're using, you'll often find that day two operations involve some kind of break glass scenario. That means that anytime you need to make a significant change and you're kind of worried about it, you probably don't want to continuously deploy it. And so you'll look at your GitOps framework and assess what the blast radius or criticality of the resources you have. If they are extremely critical resources, you'll turn off any automatic synchronization, you'll pause it, and then you'll have to go back and reconcile it. So in this case, right, I'm going to keep things out of sync until I make changes somewhere, and then I'll come back and synchronize it so that it's all updated and everything is the correct version that I expect. So this works pretty well. Except what happens when there's the absolute disaster scenario. So forget like day two, but maybe it's day three and it's exploding, right? This is where the escape hatch becomes more important. When no matter which way you choose, no matter which interface you choose, you need an escape hatch and guess what, it's version control. So anytime you go in and you make a change to version control, that as it's sort of lowest level interface should cascade to every other interface that you have. And this is kind of complicated, but for the most part, I think we've all established that we've done everything as code, whether you're doing it through Kubernetes, some in infrastructure as code, or any other programming language, we're all doing it in version control by now, and we're able to push those changes out. Now there are some nuances. If you're making some changes and you need to make break glass and you need to go to a console, you have to go back all of your layers of reconciliation so that everything in automation makes sense and you don't have that drift anymore. So in the end, you have abstractions with options, right? You have many different options in the form of a platform interface and you can choose whichever one you want. But at the end of the day, I hate to tell you this, but you have many, many, many of them that you'll have to support. So whether it's infrastructure as code, to GitOps, to UICLI, a lot of the ecosystem you see now has all of them for you to use and for your developers to be happy. Thanks.