 Thanks everyone for coming over here. So again, we'll just, Jules and I will quickly kick off the track and then you'll take it from there. To quickly introduce myself before that, I'm Sanjay Patil from SAP. I am a product manager for SAP Cloud Platform working from Palo Alto, California office. I have been involved with Cloud Foundry for quite some time and the topic of containers has been very near and dear to my heart. In fact, at the Boston Cloud Foundry Summit, I gave a talk on why do I need Kubernetes when I already have Cloud Foundry. I named the title a little bit attractive, but the topic was pretty close to what we'll be covering here. So it's really exciting to see that at this summit we have an entire track focused on this topic. So let's kick it off. So I thought let's just start with a couple of haikus just to lighten the mood over here. I'm sure many of you have seen the Haiku for Cloud Foundry. This one is by Anzi. Many of you know him and as it reflects upon the main benefit that Cloud Foundry brings for the developer, whereby developer really focuses on writing the application code and then the platform takes care of finding the right binaries for the run times and frameworks, creating the deployment, standing up the instances of the server, doing all the plumbing, scaling, logging, security, all the good stuff you need for running an application. Awesome stuff. We are totally into this idea. We are very passionate about this idea as a community and we are perfecting this art over the years. That is really great, right? However, meanwhile, we also see this another movement in the industry which is reflected by the Haiku on the right side, which probably is not as popular in this community as the one on the left side. This Haiku is saying that the developers, some of them, are not quite happy to be at a distance from how do I drive the infrastructure. These developers want to get their hands deep down into defining the deployment, customizing the deployment to the specifics of their needs. There are many scenarios in which this is needed. I think at the keynote as well, some of the speakers spoke about this. You might have creation of stateful services, backing services, what have you that requires more finer-grain control over where the application runs. Maybe your application requires a GPU server. Maybe you need to spin off an entire cluster to isolate your tenant. Maybe you need to have a couple of components always running together, or maybe they should never be running together. So for a variety of reasons, in many cases, the team of the developers want to be more precise about how the application binds to the infrastructure. And that is the Haiku for Kubernetes as is represented over here. And the source is really a quick Google search, quite handy for me. So just to contrast this, the benefit that Cloud Foundry offers in terms of the simplicity by shielding the developer from all the complexities of the infrastructure as a service, because it's an opinionated platform. The developer is really free to innovate faster. I think there was a user panel earlier on stage over here. And most of them spoke about the main advantage of Cloud Foundry is quick time to market, to bring a cultural change in the company, because now developers can quickly be productive. That's a great reason. At the same time, the other community, well, the containerization or the Kubernetes community wants to have empowerment with greater control to shape the deployments. So if we quickly contrast the very high level stack diagram for these two, on the Cloud Foundry side, we have this nice abstraction of Bosch that would then allow through CPIs to run the platform on a variety of infrastructures, whether it's on-premise OpenStack or any other on-premise IS technology, or most of the major hyperscale providers like AWS, Microsoft, Google Cloud, and others. So that simplifies where the platform runs. Once the developer team is used to programming to the Cloud Foundry platform, then because Cloud Foundry platform can be available on a variety of infrastructures, you can easily take your team and innovate wherever your business needs to. Likewise, on the Kubernetes side, the fact that Kubernetes can run on multiple hyperscales is also given today. And then the abstraction of the platform is also rising steadily. It is not just at the level of clusters, but now you are having past qualities also shaping up in that community. With Knit, Istio, you have similar offerings like you can push an application code, have the platform do auto scaling, even scaling to zero, blue-green deployment. So kind of you get very similar environments to have developer productivity. So on this side, you can do very simple 12-factor apps as well as stateful applications or services. And of course, Cloud Foundry is best suited for your innovative 12-factor applications. Just talking about SAP, we obviously have customers in our own requirements where we need to support the innovation platform in terms of Cloud Foundry as well as the Kubernetes clusters for our stateful service requirements. This may not be unique to SAP, by the way. This is probably a scenario at most of the customers and partners and vendors. So this is the diagram we are seeing at SAP. And it has a couple of issues with this. One is there's quite some duplication of efforts in terms of engineering, similar components doing similar things in the two stacks. We're obviously seeing a lot of give and take between these two communities. Like you can see components like Istio or technologies like Istio being used in both. Likewise, build packs are now showing up both in, obviously, they have been in Cloud Foundry from day one, but now they are showing up in Kubernetes as well. But from a customer perspective, when they look at these two stacks and they think about, OK, what do I model my architecture to, it could get confusing. So it's in the great interest of all of us and the two communities to bring these stacks together. In particular, within Cloud Foundry Foundation, there have been a few work streams to bring these two stacks together. The first one is about publishing services from both of these walls and having a single catalog of services so you can cross-consume services. A low-hanging fruit, a necessary thing to take a step forward to bring these two stacks together. The second one, and this is probably what Jules will talk a lot about in his technical talk later in the day. Is it today or tomorrow, Jules? It's today at five. Be there or be square. Yep. And that will then talk about how you take a Cloud Foundry application and schedule it on a Kubernetes cluster. That's probably the next leap in this path of bringing these two stacks together. And the third one is pointing at how do you containerize the entire Cloud Foundry control plane and run it on Kubernetes. So that is just tip of the iceberg. There are lots of topics where there is a great innovation going on in the community. This is just an opening of the whole track. I have just put a screenshot of the presentations on both the days over here. Please stay around and enjoy the talk. So I think with that, Jules and I want to get out of your way and have you get into the actual session presentations. Thank you.