 Good afternoon, everyone. How's everyone doing? Good. Thanks for coming here. I have five minutes. Lightning talks out the most trickier one, okay? And they didn't even announce what I'm talking about, so I get the freedom to choose what I want to talk about. So how many of you really remember that you're at Cloud Foundry Summit and you're not at a Kubernetes Summit or some other place? It's hard to keep track, right? There is multi of everything, multi language, multi cloud, multi environment. So what I'm going to talk about in the next five minutes is this multi-star environment and what is the path forward? What is SAP's approach? I want to share that with you openly, so if there are common interests, we can collaborate together. So we love Cloud Foundry. SAP has been part of the Cloud Foundry Foundation since its inception. We have lots of engineers contributing code, driving projects in Cloud Foundry. What do we love Cloud Foundry for? We love it for its simplicity to have a platform for agile innovation. And we always start with multi-cloud. We do respect our customers' choice of having their applications wherever they want on any public cloud. So multi-cloud is always our starting point. Then we got Cloud Foundry on top of it, not just technically enabled, but actually running on all these multi-clouds. So you can build an app, pick which cloud you want to deploy the app on it, and you got it. You don't have to separately enter into a contract with that public IS provider. And then you can have services either as part of the Cloud Foundry platform or elsewhere deployed, but consumable from apps that are created by the Cloud Foundry directly consumed there. So Cloud Foundry, great platform for 12-factor apps, very simple experience for the developer, and the platform takes care of all the hard stuff of scalability, availability, resilience. However, there are other scenarios. For example, there are cases where you need to have the full application stack. The developers are powerful developers. They think they know what they're doing, so they want to have the application stack, the underlying frameworks, everything packets together. And what's a good environment for these containers? And in many cases, the developers want to have exactly the same image on development environment, in development environment, in production. So if something goes wrong in production, they don't want to run around trying to figure out what code was running. And in many cases, they want to have a greater freedom over where these processes are deployed. If you have a machine learning application that runs on GPU server, you don't want the platform to arbitrarily shut down a process in one place and spin it off in another. So for example, in SAP, we have some teams that are consciously chosen to use Kubernetes. Here's an example of a very complex data landscape. What's the main problem in bringing the complex data landscape together? The links between the different data silos. So we have a product called a SAP Data Hub. What it does is it allows you to keep the data where it is and then use this distributed container environment to take the processing closer to the data. And once you take the processing closer to the data, depending on the system that you're working with, you might need special libraries that work really well with that data source. You might want to combine some processes that run together as part of the pipeline. For all of this, while it's good to have a simple development experience, you also need control over how that process is realized, right? That's the Kubernetes environment. Implementation of services like blockchain, very compute-intensive processing, like machine learning on GPU. Over here again, it's not sufficient to just have a simple development experience. You need greater control over the infrastructure. Another example, SAP Concur is a travel management solution used by millions of users globally. They need it highly available, highly scalable, available all the time. Application, which you cannot just do CF push, right? So over here, we're transforming this entire application by taking groups of services, one at a time, programming it in Kubernetes. So we need Kubernetes environment as well. So we again start with multi-cloud, and then we build different services on top. We have something in the middle. We have an open source project called as Project Gardener, which I'll talk about in a minute. Using that, then we build services and apps, right? So this is the path forward. But while we support both Cloud Foundry and Kubernetes, we don't want to have these just as options that would confuse our customers and partners. We want to have a combined vision. Here is a combined vision. Multi-cloud as a starting point. Use Project Gardener to have an abstraction, a uniform layer using which you can have Kubernetes cluster as a service on any public cloud that you would like. On top, then you would have applications and services that are native to Kubernetes, as well as Cloud Foundry itself as a workload on Kubernetes so you can then have apps created by Cloud Foundry. Single environment, don't try to solve the same problem multiple times. So that's the vision we are headed. For this, we have Launch Project Gardener. Open source project, check it out on GitHub today. The simple idea is this. If you have a Kubernetes cluster, it has master node for control plane, worker node to run your workload, right? Now, if you have multiples of these clusters, you've got a lot of these clusters, each one having control plane and the actual workload, right? To maintain all of this homogeneously, it's a complex task from an administration operational perspective. So what we're doing is really simple. We're taking the control plane from the actual clusters running your workload, bringing it into a dedicated Kubernetes cluster and the workload for this dedicated cluster is the control plane for the rest of the clusters. Very simple idea. So we're using Kubernetes to bring availability and scalability of Kubernetes. So that's the idea over here. And in Cloud Foundry Foundation, we are part of a series of work streams to bring Cloud Foundry and Kubernetes stacks together. The first one utilizes services, publication and cross-sharing and lots of engineering componentry instead of reinventing the wheel in multiple places. Second one is to have Kubernetes scheduler running the Cloud Foundry workload. So if you do see a push of an app through your regular see a push environment and instead of going to Diego, the workload goes to a Kubernetes scheduler. The last one is to actually containerize the entire control plane of Cloud Foundry and run it as a workload. So there are different companies leading it at the moment, but we all are working together and taking this entire journey forward as a community project. So my last slide. The reality of today's times is multi-language, multi-cloud, multi-environment. And it's probably going to be like this for the next two, three years, right? So we all have to figure out what's the best path forward over here. So in that regard, there are a couple of few of these open source projects we are driving. So this is a call for action to the community. Come on, join us in these projects and let's have this journey together. Thank you.