 So Florian, come on up and show us. Good morning. Let me set up my laptop quickly. Okay, so I'm going to talk about the service mantras and how we use it at SAP. So we have the simple scenario here, why Cloudtron is talking to a service broker. At simple, that's the open service broker API, nothing special. So let's add another service broker to the picture. Well, nothing really changes. It's the same API. It's still manageable. Everything is fine. Let's add Kubernetes to the picture. Also not a big problem because it uses the same API. It's the open service broker API. So the service couple working in Kubernetes can use the same brokers. No problem. So now let's add a few more platforms to the game. So when we're talking about the SAP Cloud Platform, we have thousands of Kubernetes and Cloud Foundry instances running. So just a few on the slide. Now let's add a few more service brokers to it. At SAP, we run hundreds of services. Now let's connect them all together. It's a mess, right? It's not just a mess on the slide. It's also a real mess in reality. So we need to find a solution to manage this mess. And the solution that we came up with is called the service manager. The service manager will become a central component of the SAP Cloud Platform. So platforms will be registered at the service manager, and brokers will be registered at the service manager. So whenever we add a new platform to the SAP Cloud Platform, we will register it at the service manager, and the service manager will know which brokers have to be registered there. So the author of the service and the service broker doesn't need to know what's actually going on. The service manager will have its policies, and based on these policies, it will decide which broker goes where. The same is true for the service broker. So when we have a new service broker, a new service, we add it to the service manager, and the service manager will then distribute this registration to whatever platform we think it has to go. On the way, we can also apply policies like, well, the service broker provides service ABC, but this Kubernetes cluster here should only see B and C. So we can change the catalog, we can modify the catalog of the service broker on the way to the Kubernetes cluster. The nice thing about this approach is that we are using the open service broker API, and we basically don't need to change anything, right? So we don't need to change anything in Cloud Foundry, we don't need to change anything in the service couple of Kubernetes. It's still the same API. All the native tools are still working. All the user experience is the same. No application has to change. It just works. The same is true for the service broker. We have a lot of service brokers, and they probably don't need to change at all because it's the same protocol. There are, of course, a few exceptions. There are service brokers that are specifically built for Cloud Foundry or for Kubernetes. Those, of course, have to adapt a bit. But also this is something that we can control via policies. For example, if a service broker tells us it only works really with Kubernetes, we only register it at a Kubernetes cluster, not in Cloud Foundry and vice versa. We also get some other nice features from this architecture. We can provide functionalities that span platforms. One of the most important ones is instant sharing across platforms. One of the scenarios is you create a database for a Cloud Foundry application, and a year later you need the same database in a Kubernetes cluster. This is something that we can do with a service manager transparently to the platforms. Neither Cloud Foundry nor Kubernetes will actually identify this as something hostile or different. This is completely built on the Open Service Broker API. We know that we are not the only one having this issue because there are other providers that have a lot of platforms and a lot of services. Right from the beginning, we started the service manager project as an open-source project. The project is called PeriPly. You can find it on GitHub. PeriPly is basically the framework for the service manager. What we are doing basically is adding plug-ins to it. There's a plug-in framework that lets you extend the service manager framework of PeriPly, and that's what we're doing at SAP. We are not forking our own project and then changing it to fill with it. What we are doing is we are building plug-ins for it. Those plug-ins and implement things like the policies I talked about. Policies like which broker should be registered where is something that's really specific to the environment. This is not something that you can build in an open-source project with a set of simple rules. There's really need some coding and maybe also talking back to the platform itself. What we are doing is we are taking this, adding plug-ins to it at SAP, and using it at SAP. I now want to show you a little demo. I will register a service broker at the service manager, and this service manager has a Cloud Foundry in the Kubernetes cluster attached to it. It's only two platforms here, but you can imagine the service manager handles hundreds of platforms. All I'm going to show you is the open-source code here. Everything I'm doing here on stage, you can do yourself by just taking what's on the GitHub project and set it up yourself. There's no SAP-specific code in this demo. It's a live demo, so let's see what goes wrong. Basically, I have three windows here, and it's already shifted. Three windows here at the top, I have the service manager window where I run service manager commands. This red window here, I have Cloud Foundry. I use the Cloud Foundry command line tool, and down here I use the service catalog command line tool. Let's see. As I said, I've registered two platforms at the service manager that you can see here, and there are no brokers registered at the moment, so it's a pretty empty system. Let's look at Cloud Foundry. There are a few brokers registered here, but nothing of interest for this demo. Let's try the same on Kubernetes. No broker registered here. Now register one. I have a little currency converter service that converts currencies that I use for the demo. Let's see. It has been registered. I list the brokers here. We can see this now on Cloud Foundry. Yes, we can. There's a node broker that starts with SM proxy. That's a service manager proxy that takes the role of the original broker, and we should see something similar now on Kubernetes. Yes, it's over here. Let's use it. Let's go to the marketplace. Now we have our currency converter service here. Let's create an instance. Create a service key. Here we are. There's a UL password in the username. Let's use it. Okay, good. It's working. Let's try the same with the Kubernetes. Here's our service. Let's create an instance of that. Let's create a binding. Of course. It's our live demo, and it doesn't work. But, yeah. You can imagine that basically the same thing works in Kubernetes as well. I was able to create an instance of the communication between the service catalog in Kubernetes, and the actual broker did work, but for some reason the binding didn't work. I don't know. I have a session about the service manager later this afternoon, and I will try this demo. If you want to know more about the service manager, more details and what we actually do at SAP with it and what kind of plugins we write and things like that, I will show you there. Thank you.