 Our approach is going to be provide those core services along that continuum of cloud to edge, but be able to do so in a way that's very portable, very cloud agnostic, open source friendly. So you, as a developer and as a business, have greater control, ownership, and agility of your applications. Because you may choose, let's say, Google Cloud Platform for this particular region because they have great regionality, let's say, in Europe, where you may use Linode Akamai because our Kubernetes engine is so simple and powerful, where you may use Azure for something else. So whatever those combinations are, we want to make sure that the customer is in control and can choose the best product or best vendor for the right situation, the right workload, the right use case with third-party tools like Ansible and Terraform and others and a lot of these integrations happening and companies like Akamai Linode that are making it easy to run multi-cloud is much more possible than it's ever been before and I think that's a really, really good thing. I'm seeing a lot of frustration around cost and more and more these days around egress. Egress seems to be the bane of everyone's existence and kind of especially as you go up the market and you're into more streaming and other things. So that's always been a good point for us to kind of touch on is we bundle in a bunch of free egress and when we can show people how much free egress they're getting, that's really attractive. So something that's fairly new to us and I'm not sure that it's easy to observe outside looking in is that we have been moving towards some more managed services, services that are a little bit more, dare I say, complicated, simple. They're built to be simple but they are more technologically complicated. Kubernetes managed database are basically what I'm talking about here. When we began offering those things that changed how we do support. And we know that the developer community that Linode has been a part of for so long you wanna get your hands dirty. You wanna be maybe deploying some of these things yourself, managing them yourself, really understanding the build and the structure of your architecture or of your infrastructure. And while that is great, you hit a certain point where you get impacted by some of the daily monitoring or maintenance requests or version control or updates that need to be done for your Manit or for your Kubernetes cluster or for your database cluster. And those are two of the most needy applications or components within your stack. So we, as he said, we just wanna make it easier. We take that to heart in every deployment but as we look at things that people are excited to deploy need within their architecture design because if you're creating an application it most likely is translating or needs an input for some kind of data. So you needed to be able to manage that and monitor it and care for it and the care and feeding of those things takes a lot of time. I think what's important is that you can, you can choose your path, right? You can actually today run a Kubernetes application without using our managed Kubernetes or you can choose to use the managed service. And it's really depends on what's right for you. To be able to roll your own may make a whole lot more sense than using our managed service which we try and put the easy button on it. We try and make it as easy as possible for those that, you know where that capability is gonna work for them. But if you have something very sophisticated or very custom being able to roll your own may make more sense. So I think the idea as long as you're offering that sort of duality or those two options I think you're in good shape. It's beautiful. Like, and it's, I'm more and more like that hesitation towards adopting it really it's there to make your life easier. It's what it is. And I can see why it's intimidating in the sense that like if you take a course like a Kubernetes 101 course and at least a lot of the ones that I took when I first started getting involved with it it started with the beginning of how it all kind of works and bootstrapping your own cluster which I think there's definitely, you know a good learning step. But that in itself I can see where that becomes intimidating because bootstrapping a cluster, right? It's just like this explosion of components that come out. We've always been a support team that were experts in Linux but not experts in the managed version of Linux things, right? We expected that to result in more technologically complicated questions configuration, installation, troubleshooting around databases, around all these other more complicated things like Kubernetes. We're not seeing that. And I think that that's a testament to how simple we built those services. We do get them and we have a really fantastic training team and we were prepared for these things. We learned about databases prior. We learned about managed databases prior. We learned about Kubernetes. We're getting Kubernetes certifications, SQL certifications, all kinds of certifications. But we built it to make it really easy for customers. Those customers who are buying the managed version they often already had an unmanaged version running and this is a simpler version of that. So that was sort of an unfounded fear that we had. And again, I think it shows that we built true to what we've done in the past, a really simple, easy to use, transparent version of what customers need to solve their problems.