 All right. Good afternoon, everyone. This is the talk on why do I need Kubernetes when I already have Cloud Foundry. Just wanted to make sure that you are in the right place. You are in the Cloud Foundry Summit. There are a bunch of conferences going on, and we are hearing all these different buzzwords, so it's easier to get confused. Anyway, so my name is Sanjay Patil. A quick word about myself. I work at SAP as a product manager in SAP Cloud Platform. I have been in the tech industry for over two decades. I have had an opportunity to work on application servers, integration broker, middleware like Corba, B2B, Web Services, and now Cloud Platform. So I have a lot of gray hair, and my wife told me one day that my hair was dark black until I started looking into Cloud. So yeah, that apart. The topic that I want to cover is why is SAP looking into Kubernetes when SAP has already been committed to Cloud Foundry for so long, and what's our perspective in bringing these two things together? So this is not a product roadmap presentation by SAP, but the main intent here is to share the status and thinking at SAP so that we can explore collaboration opportunities wherever there is common interest. So that's really the candid agenda I have over here. And the way I want to address or go through the different topics is first talk about the role of Cloud Foundry in SAP solutions, particularly SAP Cloud Platform. As I mentioned, SAP is heavily invested in Cloud Foundry. We have been a member of the Cloud Foundry Foundation since its inception. Several of our engineers have been making leading contributions to Cloud Foundry open source projects, and we continue to do so. So that's the first thing I wanted to talk about and set aside. Secondly then, there are cases where the Cloud Foundry paradigm is just not a good fit, and I want to take some concrete examples of SAP's own solutions where engineers made a conscious choice to use Kubernetes. And I wanted to put that into perspective, and then talk about path forward in this multi-environment world where we have Cloud Foundry, Kubernetes, and legacy and other environments. So that's the general high-level agenda. And I'm guessing that this is a topic that's also being discussed at several of your companies, so what I'm going to talk about probably will make sense to most of you as well. So this is a high-level overview of Cloud Foundry environment in a SAP Cloud Platform. I think this will be more or less similar to most providers out there. So what you see right there in the center is the application. So obviously, application is the king, and then the application could be programmed using variety of programming languages, Node.js, Java, Python, Ruby, PHP, Go, and you can always add new languages using the Cloud Foundry build pack mechanism. I'm sure you all are familiar with that. And then to expedite innovation, there is a variety of backing services. Popular backing services like PostgreSQL, RabbitMQ, MongoDB, Redis, and SAP's own in-memory database engine SAP HANA. Then what you see on the other side from here are the typical platform services for scaling, logging, scheduler, and then on the right-hand side, security service that can connect to your on-premise or corporate identity provider, whatever you may have. And then obviously, Cloud applications are great, but Cloud also needs moisture, and it gets moisture from the ground. So just like that, any Cloud application always needs some data and functionality that comes from on-premise systems. So there has to be a connectivity service connecting you with the on-premise or other Cloud applications. And then there are a series of innovation services like IoT, machine learning, using which you can build powerful Cloud applications. One of the unique aspects over here is all of this platform is running on public Cloud infrastructures, like AWS, Microsoft, Azure, GCP. And this is not just technical enablement that you can take it and run on different Clouds, but SAP's Cloud platform is running on these different public Cloud infrastructures. So you can build an app and pick and choose which Cloud APIs provider you are interested in and deploy the app over there. So the customer does not have to enter into a contract with the public APIs provider separately and get a different bill, which is all taken care underneath by the Cloud platform. So a typical Cloud Foundry application looks something similar, like you first of all have application programmed in any language using a bill pack, and then most applications do require either a data persistence, data messaging, or some backing service so that the application itself remains stateless. That's the main idea behind Cloud Foundry-based applications. The application developer focuses on business logic, specifies dependency on backing services, platform services declaratively in manifest.yaml, and does a push of the code, and then the platform takes care of looking into the code and the dependencies, creating a droplet, spinning off instances of the processes, doing service binding, and doing all the hard work. So it is a simplified platform for application developer so that the hard stuff like help management, scaling, resiliency, all that is taken care of by the platform. Pretty powerful model, and therefore obviously why SAP Cloud Platform has been supporting it, and we plan to continue to do so. So having said that, there are other scenarios where this paradigm is not a perfect fit. We engineers always want new things, obviously from a technical perspective, but there are also cases where we have to think about new scenarios and new solutions for scenarios. The first one I want to point out here is a custom development of the full application stack, not just the business logic, but the frameworks, the backing services, all of this entirely designed by the developer. So if you think about Cloud Foundry paradigm, there is a separation of concern. Application code is what the developer focuses on, and backing services, and the entire platform is managed by the Cloud Foundry platform. So pretty, as I said, it's a very powerful model. For example, if there is a security patch that needs to be applied to one of the backing services. With the Cloud Foundry paradigm, the security patch management can be done at the platform level. The developers need not be bothered about that. However, there are scenarios where developers want to take care of the entire stack. There may be some custom binaries that needed to be added to the application stack. There may be some custom configurations. So these are developers who know what they're doing, or at least they think that they know what they're doing. And we need to provide them the platform. So that's the first scenario. Secondly, there are cases where the application package, not just the code again, but the entire package, the developer or the development team wants to ensure that the package is identical in development environment, in testing, in production, so that if there are any things that are broken at runtime, the developer does not have to go through the nightmare of figuring out what exactly was the stack that was running in production, right? So you want to have a high fidelity of the entire application package in all of your stages of development. Of course you can do that with Cloud Foundry as well, but you typically would need some careful processes and some careful considerations of managing your configurations. Whereas I think most of you would agree that the container-oriented development has much more higher guarantees of maintaining the same container image across the different environments. So there are these cases. Then there are those cases where the application team requires a greater freedom, a greater control or infrastructure binding, network designs. Cloud is a pretty powerful thing, right? So you push the application and the platform runs the code for you. But in order to give you that simplicity, Cloud has to do a lot of things in the background, right? So like, there's a nice restaurant, you get nice food, but you don't want to look into the kitchen how things are being done. So just like that, right? In the case of Cloud, there may be a lot of moving parts. The backing service that is right next to your application during one deployment, after some time, the backing service might be removed, right? So there may be these process topological changes that may be happening in the background. But there are cases where the application just cannot tolerate any changes in the overall runtime process architecture. Like, for example, think about machine learning application that is expecting the deployment on a GPU server. You cannot arbitrarily move that application from the GPU server to another server just because Cloud wants to make that decision. There may be cases where you're building a multi-tenant application. And the multi-tenancy design might require that there is a set of processes that are contained in an isolated network. So you cannot arbitrarily move processes from one network segment to another. Your application design might require that some processes run always together on the same host. Or alternatively, there may be cases where the two processes can never run on the same host. This is application designer's choice. So what you're looking at over here is greater control over not just the application design, but how it is bound to the underlying infrastructure. Similarly, for resiliency, high availability requirements, there may be some special considerations where the application designer might want to again specify how infrastructure is utilized. So general-purpose platform just might not cut it. So these are some high-level scenarios. Now, as I mentioned at the beginning, I'm going to talk about how SAP solutions have made a choice of using Kubernetes for similar requirements. So is there a platform for handling all these scenarios you just talked about? The answer right now is Kubernetes. But you never know. Tomorrow there might be something else. I still have lots of other here that need to become gray, so I'm still saving them for the next innovation. But in general today, Kubernetes is the answer for handling all these scenarios. This is a high-level overview of Kubernetes. This is not a tutorial on Kubernetes. I'll touch on only few specific aspects that are key to my talk over here. So the core idea of containerization is that there's a container that is representing the whole application process. What is a container? A container is a standalone application package. It's simple, standalone, and it includes all the bits of the software, right? The application code, the runtime, different system tools that are needed, settings for consuming your infrastructure like disk space and everything. So this container image, once you build, then it can be deployed in Windows environment, Linux Unix environment, and it will run identical. So that's at the core. Then there's this concept of grouping together related containers in a pod. And the pods then get deployed on nodes, right? Which are your physical hosts or virtual machines. And a bunch of parts together then represent a specific service, right? So if you think about this model, from a developer's perspective, you're thinking in two ways. One is what is my application logic, right? What are the different binaries, frameworks it is using, and how do I structure my application in terms of one or set of container images. So that's a pure application functionality perspective. At the same time, in parallel, you're also thinking, how would this get deployed? What is the process architecture at the runtime? Which process needs to run on which specific hardware? How do I manage scaling? That is taking into consideration the specific requirements of my application, not a general purpose scaling or availability solution. So this paradigm of a simpler development view of container-based programming, as well as this powerful mechanism and freedom to control the infrastructure utilization, that is what is setting Kubernetes model or the containerization model apart from the other platforms like Cloud Foundry. So having said that, what are the solutions at SAP that are leveraging Kubernetes? There are many at the moment or more on the way. I'm going to talk about some of them. First one, let me spend a few minutes on an emerging solution at SAP called as SAP Data Hub. So what is the most important asset in any enterprise? Data, right? Exactly. So where does the data come from? So different departments have their own data sources, data types, data systems, and then there are the silos of departments that have their own data warehouses, data maps, operational applications. Whereas in the business level, the business users want analytics, powerful operational applications. They want to share this data with these partners really quickly. So this is an age-old problem, right? We're not talking anything new about this. Anybody who has been in the industry for some time knows that we always keep talking about this problem. So why has this really not been solved once and for all? That is essentially because I think at the core of it, there are many challenges, of course, but a key problem there is the data silos are not connected really well. There are missing links, right? That's the fundamental problem over there. I'm not going to claim that we have arrived at a solution that is going to fix it forever, but here is an attempt from SAP to solve that problem called as SAP Data Hub. So this slide looks a little bit busy. I just directly took it from a marketing team, but I'll talk about the core point of this slide, which is to leave the data where it exists today, not try to bring all the data in one central location. That just doesn't work. Your vendors might tell you that, yep, let's use this solution and bring all the data over here. We own the data and we own your business. This never works. So you've got to leave the data where it is today, and of course then at the same time, want to have central governance. So you need a solution that allows you to do central governance while keeping the data where it exists today. So that is essentially the core idea over here. And how are we doing it? Again, I'm not going to go through all the details of the product, but let me directly cut the chase and go to the core design element of ACB Data Hub, which is that there are many enterprise systems that hold data, big data systems, cloud storage or applications, right? And to bring all of this together, what this solution is doing is building powerful data pipelines in a push-down manner, meaning you construct, you design the data flow, and then you deploy this application so the actual elements of processing that need to operate on certain data storage will go close to the data storage or data system and do that execution. So the idea here is to have a pipeline, which is a computational graph, and computational graph is essentially a network of operators. And each operator is then basically designed to the data system it's working with. You can imagine operators for Kafka consumers, another operator for HDFS producer. So if you now think from a developer's perspective of data pipeline, the developer of this pipeline knows what needs to happen. Not just that, the developer architect also knows that where a specific operator needs to be deployed, right? And what kind of different operators in this computational graph need to be clubbed together, how they need to scale. So directly, in your mind, you can map these requirements to Kubernetes, right? It's not just the application design, but it's deployment architecture, which is germane to this whole realization the development and implementation of this data flow. So this is one example. And there are other cases that are not pointed out over here. For example, you have to trigger a certain data pipeline when some data changes somewhere. Your businesses want to be responsive to handle any new threat or any new business opportunity that gets typically reflected because some data changes happening over somewhere. So this is more pointing to the functionless, sorry, the function as a serverless architecture, for which, again, Kubernetes is a perfect platform underneath. Likewise, for this specific solution from SAP, we have seen customers who have data on-premise. There are other customers who have data in cloud, some have in both places. By having the architecture developed on Kubernetes, we are finding a very great deployment flexibility. 50% of the customers today have deployed the solution on-premise and the rest in cloud. And this kind of flexibility is possible because Kubernetes has a much broader and greater adoption across both on-prem and cloud walls. So from that business agility perspective as well, this choice seems to be a pretty good choice or the right choice over here. Another solution, blockchain as a service. I'm sure you've heard of blockchain. Again, I'm going to spend only a couple of minutes on this topic over here. But fundamentally, what does blockchain do? Blockchain basically introduces a technology whereby you can build trust in the network without requiring intermediaries. And not requiring intermediaries tremendously cuts down your costs as well as time of processing. Lots of applications can definitely benefit from this. SAP obviously has a series of applications that want to benefit from this technology. So what do we need from an SAP's application development strategy perspective? We need blockchain as a service, right, so that then we have this ability to build trust in the network and different applications to utilize it. Now, how do you implement blockchain as a service? Right, over there again, there are a variety of technologies to be used which come with different programming, libraries in different programming languages, different implementation environments. Kubernetes comes to be pretty handy over there as well for reasons that I talked about for the case of Data Hub earlier and other reasons such as the implementation involves special hardware, custom libraries, custom binaries, and the container paradigm and the container orchestration paradigm from Kubernetes comes extremely handy over here. And the other topic of having different tenants using different network segments, that comes extremely handy for this application, for this service design as well. So essentially, you can think about the SAP Data Hub more as a quasi-platform, right? So Kubernetes is an underlying platform, SAP Data Hub is a platform on top. Blockchain as a service is more an example of backing service, right? So you might say, okay, this is obviously a case that is not for Cloud Foundry. You cannot do a CF push of an entire platform on Cloud Foundry platform. Now, I'm going to talk about another example which is more an application example. However, this is an example which is not about, you know, lightweight dual-factor apps, but this is a heavy-duty complex application called SAP Conqueror. It does, it manages travel, expenses, and invoices. It's used by millions of people across the globe. So this essentially helps you handle, you know, filing your expenses as and when you need. And obviously, these travelers on the road, they expect this application to be running, responsive, and always available. Imagine if you're trying to upload a dinner receipt after the dinner is over and you're struggling with the app, your entire party has moved out of the room and the waiter is waiting for you to be politely kicked out. You don't want to be in this situation, right? I mean, it's not a mission-critical situation, but if an app does not respond very well for a few times, you're going to stop using those apps, right? So it is obviously a requirement to have this application globally scalable, always available. In this particular scenario, the development team, when they looked at it, looked at the different choices. The main problem they were trying to solve is the application existed and they wanted to kind of modernize it, right? Use microservices architecture. For that, they wanted a platform that would allow them to piecemeal take parts of the application, turn them into services and continue on that journey. And that's where they wanted a transformative platform. And if you think in this particular manner, you need a platform that has a pluggable API that would ease integration between different parts of the application as well as the rest of your system. So Kubernetes with its pluggable API was made as the right choice by this product team. Likewise, at that time, they wanted a platform that can be quickly set up with minimal complexity. They found Kubernetes to be spun off much more easily. And while they really loved the idea of containers, they wanted to have some platform that is not tied to a specific container technology. So for this reason, SAP Conqueror, an application. So we talked about a quasi-platform like SAP Data Hub, a backing service like Blockchain as a Service, and SAP Conqueror as an application, various different large-scale projects at SAP, making choices to use Kubernetes. This is just a view of the SAP Conqueror having multiple different groups of services, or 30 services in different groups have already transformed to use Kubernetes and rest on their way. So this is, again, a quick listing of SAP applications and projects that are using Kubernetes. Services like Data Hub, Blockchain, Machine Learning, IoT, Altiscale, ASCP, Hadoop as a Service, that's considering to use Kubernetes, likewise a series of applications. And this is just SAP's on project. Our customers and partners obviously have similar requirements. When SAP partners add their own solutions, they have a very similar requirement of having a flexible platform that can be then deployed on-premise in cloud and provides the same benefits. So what is the SAP technology for catering all of these Kubernetes clusters to SAP stakeholders as well as outside? The answer there is something called as Project Gardener. I don't know how many of you have heard of it, and we have just started talking more about this, but Project Gardener is an open source project by SAP. You can find it on GitHub today, github.com slash Gardener. And the main idea there is to allow end users to create and manage Kubernetes clusters in a highly homogeneous and secure manner on any given public IS infrastructure. It's extensible, obviously, so that you can add new features and you can add support for new cloud providers. And it uses Kubernetes itself for your own health management and scaling. And I'll talk about that in a minute. So if you think about a traditional Kubernetes cluster set up, right, so it has the master nodes which runs the control planes, and it has worker nodes which run actual workload, your applications. And in order to have high availability of the control plane, we typically have multiple master nodes, so that probably is a pretty well-known concept. Now if you have multiples of these clusters for your different projects, right, you are now faced with the task of managing all these clusters independently, keep them secure, keep them homogeneous from an overall cloud platform management perspective. Pretty daunting task to keep all of these clusters well-synced up in a homogeneous manner. So what we're doing over here with Kubernetes, sorry, Gardener project, is that we're taking the control plane from these clusters that are managing the workload in a dedicated Kubernetes cluster which will run the control planes of other clusters as its workload. So we got the clusters called shoot clusters on this side which are actually running the workload, and their control plane is running in a seed cluster, and the workload of the seed cluster is nothing but control plane for all of these actual shoot clusters. And we have a dedicated seed cluster for each cloud provider per region. And to manage them, we have another cluster called as Garden that would run this seed cluster, the shoot cluster. So it's kind of like using Kubernetes to manage the different clusters and their availability and resilience. It's kind of like the movie Inception, if you have seen it, right? So actually I slept off in that movie and I woke up in the middle and I asked my wife, like, what's going on here? She said, you're probably watching that part of the movie in your dream, and if you go back to sleep, you'll have another dream and catch up with the next part of the movie. So go back to sleep. Basically we're using Kubernetes or Kubernetes to provide high availability over here. So it seems that we need both Kubernetes and Cloud Foundry. So what is the path forward? Well, integrated multi-environment is how we're looking at it. So this is one quick set of slides that should show us how we're looking at these two things. So multi-cloud is pretty essential aspect of everything we do. But we definitely want to retain and respect the choice of customers and partners to pick and choose their cloud provider. On top of that, then we have Cloud Foundry running today. And then you might have services deployed either as part of the Cloud Foundry platform, like most of the backing services, or it might be using services deployed elsewhere, right, through the common mechanisms that Cloud Foundry provides. And then Cloud Foundry creates apps and these apps would be consuming those services. Great model for agile innovation that provides the platform as a service simplicity for development team using which they can build 12-factor apps. So this provides a mechanism for customers to have centralized governance so that still lots of different teams can have their own innovation, right? And we are definitely continuing to do that. For Kubernetes, it has a variety of workloads. I talked about backing services, domain platforms, and complex applications. Over here again, we want to respect the multi-cloud aspect first and then using the Open Source Gardener project, we want to have an abstraction of Kubernetes on these different public cloud providers. And then using this, then, our teams can build services like blockchain machine learning, as well as build different applications like SAP Concur, I talked about, and they can consume the services. These services, by the way, can be exposed to not just Kubernetes apps but any other apps using Open Service Broker API concept, which SAP is supporting. So, forward, this is a combined vision where it's not an either or choice, but we want to have, again, starting with the multi-cloud, support Kubernetes cluster as a service using Open Source Gardener, support Kubernetes-based services and apps in their consumption, and run Cloud Foundry itself as a workload on Kubernetes clusters so that then you can have apps created by Cloud Foundry also running on Kubernetes and consuming the same services. That's the direction we are headed. Like, as I talked about, currently, Cloud Foundry runs on different clouds, multi-cloud approach. Kubernetes also will be supporting on multi-cloud. Instead of trying to solve the problem two times, like how does our Kubernetes cluster run on multi-cloud? How does our Cloud Foundry run on multi-cloud? We need to solve it once, right? I mean, this again reminds me of the great physicist Newton who had made two holes in his door, one for the bigger cat, one for the smaller cat, the smartest guy, all those kinds of mistakes. So these are the main Open Source project. SAP is driving in under Cloud Foundry Foundation to bring these two stacks together. There are going to be more presentations on this. There's also a panel discussion in the afternoon that might touch upon this. The first project talks about how do you publish and consume services across these two stacks? How do you reuse some of the core componentry instead of reinventing the wheel two times? How do you reuse some of the main components that are needed both of these platforms? So this is more like a must-have project where SAP is taking a leading role and driving it. There are lots of detailed requirements as well as high-level design documents that are publicly available today that you can check out. The second project, led by IBM at the moment, is to use Kubernetes as a scheduler for Cloud Foundry applications. So you can do a CF push of your app to Cloud Foundry instead of going through the Diego route and spinning off a Run-C container. It will use the Kubernetes scheduler for the runtime of your CF push app. The third project is taking that idea further and using and containerizing the entire control plane of Cloud Foundry. So you can think about the whole Cloud Foundry as a containerized cluster, a containerized workload running on Kubernetes cluster. So this is the general direction and I think this is really nicely laid out in terms of the value it provides. So the path forward is again, multi-language is multi-language, multi-cloud, multi-environment is our reality today. That's the need of the current times and we have kicked off some of these open source projects to collaborate with any and all of you who have common interest in these areas. Open Source Project Gardner is to enable Kubernetes cluster as a service uniformly across different public cloud providers. And I just talked about the three different work streams led by SAP, IBM, SUSE and others, but it really doesn't matter. We work together as a close community. So those are some of the projects over here. So that brings to the end of my talk. I can take some questions over here in the remaining few minutes. If you have more questions, I would like to point out that there is a panel discussion today at 5.25 p.m. in room 253A where speakers from SAP, Google, Microsoft, IBM and SUSE they will bring their perspective on will Cloud Foundry and Kubernetes blend and how does it blend really? And if your questions do not get answered there, if you still have more questions, feel absolutely free to stop by SAP. Both on the show floor are both number easy to remember 2-2-2. So with that, thank you so much. Any questions that I can tackle in the last couple of minutes? That's a separate one. I'm going to use Gardner to deploy a Kubernetes cluster on Amazon and that cluster will be managed through Gardner. Good question. Those are just the worker nodes. Exactly. Yes. The applications themselves communicating with each other is your question? Yes. So Gardner will manage clusters on these different public cloud infrastructures. Seed cluster, poor provider per region, that will take care of the chute clusters that run the actual workloads per region and Gardner will manage it centrally, homogeneously securely. That's the idea. All right, maybe last question because I think we might be running out of time. Right. So I didn't talk too much about the Kubernetes cloud native computing federation in this or here but SAP is a platinum member and I wouldn't be surprised if you're talking about the same project and if there are others, obviously we'll be working with them in CNCF over there. We are part of CNCF or platinum or whatever top level member. We come up with some different names for the membership but we're pretty active over there. So I'm kind of giving you a variation of this talk at Cubicon in Copenhagen a couple of weeks from now so we're deeply involved in CNCF as well. All right, thank you so much for being here and listening to this talk. Thank you.