 Next, we've got a company that was, I think, started in a garage. They've gone on to a little bit of success. And so I'd like to announce that I'd like to bring Gabe Monroy up here. He's the head of product for Azure Containers from Microsoft. So come on up, Gabe. Thanks for coming, thanks for coming. So I told all of the presenters that I didn't want to see any slides. Here we go, I do work for Microsoft. So you have to take some slides out of me. So I want to talk a little bit about something that's really passionate. I feel really passionate about it. I know Chip and some others do as well, which is the concept of the open service broker API. So I come from the world of Paz. I have been building Paz systems on container orchestration for a while. And one of the things I always loved about Cloud Foundry was this idea of the service broker. And so when we were working at Deus and we got together with Red Hat, and we sort of worked together with the Cloud Foundry ecosystem to sort of take this API that was well-established, being used in production, and pull it out into its own sort of thing, first-class thing, make it a multi-vendor effort. Google, IBM, Microsoft, lots of different folks collaborating on this. To bring this idea of a nice clean separation between applications and services. And I'm just really excited to see how well this thing is going on. The crazy idea worked. The crazy idea worked. Crazy idea worked. Let's see if we can collaborate across the ecosystem a bit. Here we are. And so for those of you who aren't familiar with this, what the open service broker API does is it connects developers with a global ecosystem of services. And so it provides a standard way for applications to connect with services, standard APIs around how to get a catalog, how to provision something, how to bind to something. Nice, easy way to integrate that into your application. And I think most importantly, what the open service broker API added was this ability to use this across multiple platforms. Now, it wasn't just Cloud Foundry anymore. I'm extending into Kubernetes and some other platforms as well. So at Azure, we take this very seriously. And we've been investing a lot of engineering resources into building a next generation broker that we call the open service broker for Azure. So this is an implementation of this new idea and talks to all these Azure services. But if you look at the bottom here, take a look at all the different platforms that are consuming this, right? That's the crazy part. This is crazy. It's not just Cloud Foundry. Other Cloud Foundry is probably the biggest consumer still. But we've got OpenShift, we've got ServiceFabric, which is Microsoft's in-house first party orchestrator. And of course, Kubernetes solutions like AKS that are consuming this. So this is really now truly not just a multi-vendor effort, but a multi-platform effort. I think it's just a great success story of what can happen in open source. Yeah, so in this case, Microsoft's really being a provider of services. But we had our first ISV day here at this event, I guess a couple days ago. And gosh, it was yesterday. It feels like a really long event already. So it was yesterday. We had our first ISV event. And the idea is that by having all of these platforms, whether you're a cloud provider that's offering services or whether you're using platforms like Cloud Foundry or Kubernetes, there's more addressable market for ISVs that want to offer their capabilities now. And that also, kind of in turn, and much more importantly, I think, the developers that are using these platforms now have a lot more capability at their disposal. So it's all about connecting these ISVs, these providers with the developers that need it. Indeed. And we're really, really happy to see this all coming together. One of the other things I like to say about this is just because you can run something in a container like a data store, doesn't mean you should. And that's another thing is just the operational realities around managing these ISV provided services is really just the operationally sound way to go about this if you're interested in SLA-backed data services as most of us in enterprise software tend to be. So in order to show this to folks who maybe haven't seen this and specifically this integration with Kubernetes, I want to just show a little bit of what the open service broker looks like from the point of view of Kubernetes. So to do that, we put together a very simple demo. This is a spring music app, which you guys have all probably seen at this point. Working with Azure Cosmos DB, if you're not familiar with Azure Cosmos DB, definitely check it out. Industry leading database, tunable consistency levels, pretty cool stuff from the Azure folks. But before we get into the demo, I think it's important to talk about this project here, which is the Kubernetes service catalog. So this is actually my first main foray into sort of the multi-vendor effort here was trying to build what amounted to an adapter between the open service broker API or the Cloud Founder Service Broker API and the Kubernetes API. And so there was a lot of work. And this is one of those areas where it was a truly designed by committee approach, which doesn't usually go very well in multi-vendor software projects. But because everyone wanted this outcome of having this broker technology work well in Kubernetes, folks like Red Hat, Google, Microsoft, IBM, were sort of the main forces in that effort, all got together, designed the set of APIs. And now the Kubernetes service catalog project is a special interest group in Kubernetes. There's software that's shipped, I believe, currently in beta at this point, and rapidly progressing towards a stable release. So I want to show folks a little bit of what this world looks like from the standpoint of Kubernetes. And just so everybody knows, Gabe also had a demo that showed the Cloud Founder Reapplication runtime binding to a service. But I pointed out that this audience might have done that once or twice. So why don't we take a look at the Kubernetes? Yeah, so we didn't choose to show that one. It's a shocker. So this is Kubernetes. And what we'll start with here is an AKS cluster. And so AZ AKS list, you can see we've got a cluster running here on Azure. And this happens to be a three-node cluster. So it's sort of standard baseline environment. And what we're going to do is we're going to take a look at the pods, service instances, and service bindings. You can see that there aren't any. Now, inside of the portal, we've got three different Azure services that are running. And what we can do is use this tool that we built called SVcat. This is something that the Azure team wrote and sort of upstreamed into the Kubernetes community to provision a Cosmos DB using the open service broker for Azure. Now, if you query this again, you can now see that there is a service instance reference inside of Kubernetes using the service catalog object model. And if you go into the portal and refresh, you can see, oh, look, there's a for service. We can see a new Cosmos DB getting stood up here. Now, with a very simple helm install, helm being the package manager for Kubernetes of the Spring Music app, we can start to see the container for the Spring Music app coming up. And there will also be a service binding that's automatically attached to inject credentials and a connection string automatically into that app. And boom, here you go. We've got the Spring Music app. There you go. So really, if you're familiar with how this works inside of the Cloud Foundry and application runtime, it's roughly the same set of gestures. I mean, it doesn't look very different. It's using the same code, same exact code on the back end, providing the same value to end users and really exciting just to see how this collaboration has actually come together. Yeah, so there's almost two things to point out. The first is that's a real live, well, recorded example of Kubernetes consuming services using the Service Broker API that we all know and love. Second, though, well, Microsoft has a great Service Broker available if you want to take advantage of Microsoft services. We do have a great Service Broker. And actually, I'm pretty proud of this one. The engineering team on this broker is top notch. And there's some special features in it. This broker happens to support disconnected resumes of async operations. So if the broker is provisioning, along running provision operation and it dies, it will automatically resume from that and pick up where it left off. So lots of production grade hardening inside of this broker. If you're into broker tech, definitely take a look at the GitHub repo, open service broker for Azure on GitHub. That's super cool. Yeah, awesome. Cool. And lastly, I think the note I want to end on here is I'm just so excited to see how these, the Cloud Foundry and Kubernetes communities are starting to really merge. I mean, this is really exciting. There's been so much talk about this, I think at the show so far. And I just love this. I mean, I view my job at Microsoft as having to empower the tens of millions of developers who are entering the market every year at rapid, rapid pace. We need everyone's collective ideas in order to make these folks succeed. And when I see open source projects and foundations like this starting to work together effectively, it gives me hope that we can actually do the right thing for all these folks. It's a very Silicon Valley, we're trying to change the world. Change the world. But it is true, I think. I know, I think it is too. So Gabe, I really appreciate you coming. Thanks for having me. All right, good stuff. All right, I need that clicker back though. Thank you, Gabe.