 Hello everybody. Thank you for staying till the very end of Cloud Foundry Summit. Appreciate it. I think many of you must be Germans because that would be a totally German thing to do, right? So we've paid for that conference. We stay till the very end. So thanks for hanging around with me for that very last session. I'm going to talk about the shape of things to come and I'm trying to make predictions on the future of Platform as a Service. So before I get started, actually a disclaimer. So that presentation will contain a fair share of Greek vocabulary and that's due to the fact that I'm going to talk quite a bit about Kubernetes and related technologies and the word Kubernetes itself is coming from the Greek language and thus are many of the spin-off projects from that ecosystem. So that's one disclaimer, but then also the other disclaimer is it's very hard to predict the future. So if you look back at this talk in one or two years from now and you find me not making correct predictions, then I'm sorry for that, but I'm trying my very best to actually forecast what I think is going to be the future of Platform as a Service. So as my legal team puts it, it's hard to do all that stuff, but I'm not going to bore you with that. Instead I'm going to talk about like the status quo of Platform as a Service as we see it today. I'm going to talk about a set of projects that I would put under the umbrella of Cloud Foundry on Kubernetes. Then I'm going to turn over to yet another set of projects that I think are worth watching, mentioning in this context, etc. And then I'm going to kind of take all those building blocks that I'll be talking about in the next 30 minutes and put them together in hopefully a consistent picture. So with that, let's talk about the status quo first. So what is the status quo? First of all, like people have some kind of infrastructure layer that they're deploying their stuff on, and that might be public infrastructures, that might be private data centers, whatever you have, and then like people go ahead and put Cloud Foundry on top. And obviously to put Cloud Foundry on top of a data center, there's pretty much no way around using Bosch for actually deploying Cloud Foundry itself. And then people start like building applications, consuming services, etc, etc. And that's all nice and fine and what everybody is actually used to in the Cloud Foundry ecosystem. But now there was this other thing actually coming down from the sky, which is called Kubernetes. And like there, yes, you also have that question of how do I actually get Kubernetes inside all those data centers, be it public clouds, be it private clouds, data centers running, running somewhere. And again, there you see that picture of you have something like an application and you have other things called a service and maybe that distinction isn't that clear on the Kubernetes side, but still like you have a relatively similar picture at least from a 10,000 feet point of view. So then, and this is also not new to anybody, I guess, joining a Cloud Foundry summit. Let's talk about what Cloud Foundry actually is and specifically Cloud Foundry application runtime. So that is an opinionated platform as a service. And by opinionated, I mean, if Cloud Foundry holds certain opinions around what an application is, how it connects to a backing service, what the characteristics of such an application are, etc, etc. And if you're fine with those opinions, then Cloud Foundry is a great platform to actually run your applications on. If you're not fine with the opinions that Cloud Foundry holds, then at least on the pure Cloud Foundry application runtime stack, you're a little bit out of luck. And this is also why people then start turning to Kubernetes for some other workloads that don't really fit those Cloud Foundry opinions. What do people like about Cloud Foundry? So we've heard it quite a bit of people like that CF push experience that focus on the developer that just wants to write code and then push it to the platform and essentially the platform does the rest. And part of that is due to the opinions that Cloud Foundry holds, if only if you can form to those, then the platform can actually make sense of your code and then put it into a running environment. But then the other part is the build packs that are actually an enabler for taking that code, filling in the necessary pieces, like what is my web server that I actually want to run my Java application on, etc, etc. And that part is like part of the opinions that Cloud Foundry holds. Another benefit that especially application developers like about Cloud Foundry application runtime is that there's other people that deal with the hard parts of actually running an application, which is patching the underlying stack. So there's always somebody that is operating that platform and oftentimes or usually that is not the application developer that's a different team. And the reason for that different team is that they can solely focus on running Cloud Foundry as a platform itself. And then application developers again can focus on writing their code, pushing that to the platform and be happy with that. Also, like if you look at Cloud Foundry application runtime, there's a lot of talk around backing services. But if you look into Cloud Foundry open source, then there's not really many backing services that are part of like the Cloud Foundry open source repost themselves. So somehow it seems those backing services that you bind your applications to are assumed to exist and are assumed to run elsewhere, I would say. So it incomes Kubernetes again, which is like much more of a generic runtime. And with generic runtime, I mean essentially that this is sometimes why people come to us and say, what's the big deal? Like why do I need Cloud Foundry? Because I can also run all those nice Cloud Foundry workloads on Kubernetes itself. So why do I still need Cloud Foundry? And the answer to that is because Cloud Foundry kind of takes away those hard steps from the application developer. But then on the other hand side, it's also that Kubernetes can run workloads that Cloud Foundry can't run. So because Kubernetes is not as opinionated as Cloud Foundry, you can put workloads on top of Kubernetes for which Cloud Foundry is not really suited. But then if you decide to actually go natively on Kubernetes, then like all the effort that is taken over by the Cloud Foundry platform and the people operating the Cloud Foundry platform is something that actually you as an application developer need to spend yourself. So that is on the one hand effort, but then on the other hand that also requires quite some more involved skills into things like how does an operating system work, which Linux distribution, do I actually choose for my container? Do I have the right channels to watch all the vulnerabilities for all the components that I pull in, et cetera, et cetera? And this is where like Kubernetes itself, at least the core runtime piece does not really help you. It helps you in terms of providing low-level primitives. But like all that task of managing then the workload on top is left to whoever is deploying workloads on top of Kubernetes. Still, and we've seen that like in many announcements during Cloud Foundry Summit and SAPs is there no different, people are running both side by side because obviously there's use cases for both. And so it definitely makes sense to look at running both side by side, which creates another set of issues actually. And those are issues in terms of if you look closely at those pictures, you will find, okay, obviously there is like both on Cloud Foundry as well as on Kubernetes a piece that schedules and runs applications, make sure that they are healthy, et cetera, et cetera. So essentially, and that's also due to the history of Cloud Foundry, you see redundancy in terms of how containers are scheduled. That's Diego on the Cloud Foundry side and that's Kubernetes itself on the other side. Also, you look into like how do people actually manage that platform and you find that obviously Bosch is an important piece in the Cloud Foundry ecosystem. And yes, there's also efforts around deploying Kubernetes clusters with Bosch. But then if you look at all the choices that you have on the Kubernetes side, that is only like one very narrow space of how people are managing Kubernetes these days. That also obviously raises a question towards the community in terms of do we want to kind of keep playing catch up games by saying, hey, this other community has great stuff. Let's go ahead and just rebuild it. Or I guess what I'm advocating is to say, let's not spend the effort on duplicate stuff that other communities are trying to solve already. But instead, let's focus the efforts of each of those communities on where that community is actually best at. And for Cloud Foundry itself, as I said, for me, that's the CF push and developer experience. Then also, there's a different set of people that are looking at that picture, which are the people that are operating that combined stack. And obviously also there, you need to know about the lifecycle management tooling, you have different ways of how you interact with the underlying infrastructure, et cetera, et cetera. So also there, you see quite a bit of duplication happening. And then last but not least, and we see that already, there's people from the Kubernetes ecosystem, which obviously also think that the CF push experience is a great thing to have. And like, instead of now looking into Cloud Foundry, there's also offerings coming up from the Kubernetes world that are set up to actually replicate that experience, but without any Cloud Foundry components in the picture. So those are the concerns that we actually see. And this is why we have come up, actually, after Cloud Foundry Summit in Basel last year with a set of work streams that I would put under the umbrella of Cloud Foundry on top of Kubernetes. So first of all, we've come up with one work stream, which is looking at the picture that I've just shown and asking the question around how can we actually integrate those two silos way better? And there's topics around how do you actually share services between those two silos? How do you do common routing and networking between those two stacks? What about user accounts? What about access management? Can you do something where, like, I don't care if I log on to a Cloud Foundry or a Kubernetes cluster, I always have the same username and password. And for the people operating the platform, there's one unified way of how actually permissions are assigned. Also in terms of persistency, so Cloud Foundry has persistency service, Kubernetes deals with persistency as well, so other things to actually combine there. So that was one work stream. Then the next work stream is talking about the Cloud Foundry pluggable scheduler. You've seen talks around that as well all across the agenda. And that essentially allows you to say, okay, if you have two container schedulers, Diego in the Cloud Foundry space and Kubernetes on the other hand, like, can we remove one of those from the equation and just use Kubernetes as the container scheduler? And then last but not least, if you look at that picture and ask the question of why is there Bosch in that picture still even with that second project, then the answer is there's still the Cloud Foundry control plane. And today the most straightforward thing is to still use Bosch and deploy the control plane of Cloud Foundry, so things like the Cloud Controller, the UAA on plane virtual machines. And the containerization efforts, containerized CF control plane is actually working on taking those workloads and bringing them over also to the Kubernetes world. So looking at that first work stream and you've seen that also in one of the keynote demos already, that is something that an SAP team has set out to actually work on, which is the topic of managing services across those two stacks. So what you want to have is you want to have a common service catalog of services that people can pick and choose from, regardless if they are running a Cloud Foundry application or a Kubernetes workload. And then you not only run one, like Cloud Foundry system, and you definitely not only run one Kubernetes cluster, but you run multiple of those. That also brings up the question of can I share service instances between the two? The usual example that I make is let's assume a rabbit MQ messaging system. Can I put messages into that rabbit MQ from my Cloud Foundry application and hook them up to a Kubernetes workload that receives that message and does something based on those messages? So also sharing of service instances is an important piece here. And Florian has talked about that in his keynote talk. So essentially all of that is built on the open service broker API and the fact that the open service broker API has been adopted in both the Cloud Foundry as well as the Kubernetes ecosystem. And it actually takes the service manager component as an intermediary that sits in between what we would call a platform. So Cloud Foundry, Kubernetes, but then also in SAP's case other platforms like Function as a service. And the service brokers that are actually responsible for getting you a service instance and service manager sits in between those and enables things like maintaining that common catalog. So what's the status there? The status is, as I said, there's a team at SAP in our SOFIA location that is working on that topic full-time. The whole topic is in the open source, which is why I bring it up here in this talk. So we're happy to receive feedback on that concept, receive pull requests on the implementation. So please provide feedback and tell us about the usefulness of the service manager component in your scenarios. So that was one of the sub-streams or sub-projects that came out of that Cloud Foundry on Kubernetes. Then the second one that people have been talking about is Irini, as it's actually called. So first Greek word after Kubernetes in that presentation. Some people call it Irini. We were told Irini is the right Greek pronunciation. And that, as I said, allows you to take one of the two container schedulers out of the equation if you happen to run both the Cloud Foundry as well as the Kubernetes stack. The goal for the end user is obviously that you keep doing CF push on the Cloud Foundry side, and then everything else is hidden underneath. So essentially, let's see what happens if, instead of Diego, those applications are actually scheduled on top of Kubernetes itself. And as I said, user experience doesn't really change, but operations does have one component less to worry about. And those applications that are still CF pushed via the Cloud Foundry command line API are now out of the sudden running on top of Kubernetes natively. So what's the status there? As was announced at the very beginning of the summit, that project is, meanwhile, an incubator project in the application runtime PMC. Again, there we have people from SAP working together with colleagues from IBM jointly on that project in the open source. The Cloud Foundry smoke test, which are like the first level of tests that you usually run on any Cloud Foundry deployment are already passing. So that's a good first sign. And the team is working on completing what is called the Cloud Foundry acceptance tests or CATS in short, which is like the next bigger level of tests that are testing actually conformance and working off of a Cloud Foundry ecosystem. Also, second Greek vocabulary coming in there. There's a project from Pivotal called Oratos, which is around log collection and log aggregation. And it's also a shared component between stuff that's been built in the Cloud Foundry ecosystem. But now Pivotal is aiming at also making those components available, as I said, around logging in the Kubernetes ecosystem. So that was the second project under that Cloud Foundry on Kubernetes umbrella. And then lastly, as I said, you still have the Cloud Foundry control plane, Cloud Controller UAA. And the task of the third project that I wanted to mention under that umbrella, the project Fisile or Fisile++, however you want to call it, or CF containerization, as it has been now officially called, is to do the following thing. If you closely watch the picture, essentially taking out Bosch of the equation, running also the Cloud Foundry control plane components on top of Kubernetes and essentially making Kubernetes the single API that sits in between all the workloads on top and the underlying infrastructure providers. So my wish list item there is actually Cloud Foundry obviously keeps evolving over time. And there is the well-known CF deployment, which is essentially creating new versions of Cloud Foundry every week. And I am advocating for actually getting a similar project that kind of deals with creating a containerized Cloud Foundry deployment and essentially kind of pairing that with CF deployment and therefore making sure that whenever a new Cloud Foundry version is tested and released, that you not only can deploy that new version on top of the M-based infrastructure, but you can also take that version and deploy that on top of Kubernetes. What's the status there? Again, that project is now an incubating project this time in the Bosch PMC. And that is under heavy contribution from SUSE and IBM and SAP's Bosch team is about to start first work items on actually doing changes in Bosch that are reasonable also for other scenarios, but that are also helping to move that project along. What also helps there is another effort coming from other colleagues from Pivotal, which is called Bosch Process Manager, which essentially is an effort to even in the VM-based deployments of Cloud Foundry use containerization on those VMs. So essentially isolating the different processes that are running on a virtual machine using Linux containers, C groups, et cetera, et cetera. And obviously, if you have that in a VM-based world, you can kind of reuse that definition of what a container process is and how it's supposed to talk to other processes. You can reuse that to create pods on the Kubernetes side. So that were the three projects that I wanted to talk about under this umbrella, but there's other projects to also watch. First of all, there's the Project Gardener. Project Gardener is set to create and manage Kubernetes clusters on various cloud infrastructures. What is so special about Project Gardener are just a few diagrams to actually explain that. So usually, if we're talking about a Kubernetes deployment, you have what is called master nodes and worker nodes. So the master nodes are essentially running the control plane of Kubernetes and the worker nodes are running the actual workload. Gardener obviously takes that notion but then like dedicates one particular Kubernetes cluster and then calls that a seed cluster. And why does it call it a seed cluster? Because in the garden terminology, there's other clusters which are called the shoot clusters and those are actually managed from that seed cluster. If you watch closely and look at that diagram, you obviously see that those shoot clusters do not fully resemble the seed cluster visualization. And obviously, the master nodes are lacking from those shoot clusters. So where did we actually hide the master nodes in that diagram? And the answer is those master nodes of the shoot clusters are actually running as workloads on the worker nodes inside the seed cluster. So essentially, we are doing that whole inception thing of managing Kubernetes using Kubernetes itself. So that's what we think is a very unique approach to actually running Kubernetes. And we also know that people like Google are taking similar approaches to actually managing their fleet of Kubernetes clusters. So what's the status there and why am I even talking about that? If that is something that we build at SAP, again, that is another project that we have put in the open source. It is to my knowledge, the only multi-cloud Kubernetes as a service offering. And by Kubernetes as a service offering, I mean by that, it's not only a single Kubernetes cluster that you get from that offering, but you can essentially create a multitude of Kubernetes clusters and via that seed shoot approach actually manage all of that in a very homogeneous fashion. As the whole thing is open source, new features can be added easily, essentially by everybody. New cloud providers can be plugged in. So there's people interested in adding support for even more infrastructures to run Gardener on. This is essentially possible. And similarly, obviously, if you have an on-prem infrastructure as a service running, people are also looking into doing that. Then also, there's an effort going on to essentially standardize the format of how those shoot clusters are described, like what are the properties of those shoot clusters, what are machine sizes, et cetera, et cetera. So there's a special interest group inside the Kubernetes ecosystem, which is called the cluster management API group. And we're happy to report there that actually Gardener is the first reference implementation for that Kubernetes cluster management API. And last but not least, why do we think that this approach can scale simply because we eat our own dog food there? And Gardener will be the foundation of the upcoming Kubernetes as a server offering that's going to be part of SAP Cloud Platform itself. So definitely worth checking that out. Istio, I think many people have also talked about Istio during Cloud Foundry Summit. It's a framework to connect, secure, control, and observe services. And it has neat properties that actually allow you to kind of offload the work that traditionally in Cloud applications, distributed applications that are communicating to services via the network had to be done traditionally in application coding. So nasty topics like how do you actually do routing and load balancing between a client and then potentially multiple virtual machines or multiple endpoints that are running your service? Also, it's a language agnostic approach. So whereas you might know language specific libraries or components that deal with those efforts, Istio is an approach to say, let's use Istio itself regardless of the programming language that the actual application is written in. Same goes for policy enforcement and telemetry and reporting. And also, and Shannon Kohn has given a talk yesterday on that topic, Istio is like a very promising technology and that's why the colleagues from Pivotal are also looking into making Istio an integral ingredient of the Cloud Foundry routing layer, be it both for incoming requests but then also for requests between Cloud Foundry applications as well as between Cloud Foundry applications and backing services. You might have seen that diagram, how does Istio achieve all those properties? So essentially, you have a consumer of a service and you have the implementation of a service running somewhere and Istio uses another open source component called Envoy and that is sitting in between the network path of the consumer and the service provider and by plugging in into the network path but not running inside the same process than the consumer and the service itself but running as what is usually called a sidecar process to that. You can imagine that this component can work even if the consumer is written in Node.js or it's written in Java or in Go. So because essentially those Envoy proxies are intercepting network traffic only. And then you have those Envoy proxies and you have a whole lot of them because like each consumer and each service provider has own instances of those Envoy proxies. You essentially have a control plane that is kind of remote controlling those Envoy proxies distributing configuration, doing policy checks, collecting metrics, dealing with TLS certificates, etc., etc. So that's how Istio achieves the properties that I just mentioned. Last but not least, the last project that I wanted to mention is Knative. Knative, if you look up its definition, is a framework of opinionated primitives for building modern source-centric container-based applications. That's a whole lot of buzzwords, I guess. So let's look into what Knative actually is. Knative is a framework or a set of building blocks that's actually sitting on top of Kubernetes and Istio and it's itself subdivided into separate components. So the goal of Knative itself or one of the goals of Knative itself is to unify the platform as a service space and the function as a service space, which is also like something that's pretty unique in terms of the approaches because so far like the people on the platform as a service side did their own thing and also on the function as a service side, you saw quite a lot of frameworks but like there was not too much interaction between those two communities so Knative is set out to change that. And as I said, Knative has a couple of building blocks so one is called Build and whenever we talk about running workloads on top of Kubernetes, obviously one of the questions is how do I get to my container that I can then ultimately run on top of Kubernetes and Build is actually set out to take over that task so Build is designed to actually create those container images and that might be creating those container images on the Kubernetes cluster itself. It might be delegating that task to a remote infrastructure but Build is like an abstraction layer that allows people to create container images in various ways. Then there's what is called the serving component, another set of bus words, so that is a scale to zero request driven compute. So what does that even mean? You might know it from the function as a service space where like one of the properties is to say if there's no load to process then like I don't want to use any compute power and what's also important for people I don't want to pay for resources that are essentially idling. So Knative serving amongst other things implements what is called a scale to zero component so that essentially allows you to only wake up particular components if they have to process requests and otherwise put them to sleep but then also like scale them up very rapidly if you actually find out that hey it's shortly before Christmas and people are kind of rapidly wanting to purchase items from my store. So that amongst other things is what serving is set out to do. And then last but not least, eventing. And that also is another property that mostly comes from a function as a service space but you could as well imagine that to be very relevant and useful in the platform as a service space. So typically in function as a service architecture you want to listen to events that are created elsewhere and that elsewhere could be like an SAP ERP system that could be another part of your cloud but you want to have like a function or even a platform as a service type of application that is then receiving or subscribing for those events receiving events as they happen and then start processing based on the payloads that those events are actually carrying. What is not pictured are recent amendments to Knative so it's definitely worth checking out what's in that Knative space. Also there's the open service broker API for anything that's related to remote services that need to be connected to the infrastructure and what is actually not yet part of Knative or just beginning to get part of Knative are things like a command line interface, a UI, a container registry that you need on top of Kubernetes etc. So what's the status there? It's a project that has been initiated by Google and being announced mid of the year during the Google Next conference and you can also see from the partners that I mentioned on that slide there's very prominent companies from the cloud foundry ecosystem but then also outside the cloud foundry ecosystem other prominent companies that are working in the platform and function as a service space. So definitely worth checking that out. Then last but not least I've presented quite a few building blocks how does it all fit together and like there had to be an SAP and vendor specific slide in that talk and this is essentially it and I get beaten up by many people inside SAP for showing that slide because like from a product marketing product management perspective it's way too complicated from an architecture perspective it's way too oversimplifying things so like bear with me for a second I'll nevertheless try to to make the case for why that is relevant. So first of all that there's still infrastructure as a service providers SAP is running our own data centers there's customer and partners that are interested in running SAP solutions in their data centers so that kind of forms the lowest layer. Then we see technologies like Kubernetes in our case provisioned by Gardner as the foundation layer as well as Istio for anything that's related to kind of software defined slash virtual networking as well as Knative as an important building block for many other technologies sitting on top and in the case of SAP cloud platform we have a set of what we call environments and that cloud foundry is one of those environments. We've recently announced a function as a service environment that you can use if you're using SAP cloud platform. We have the Neo environment which is the original core of SAP cloud platform and for the people that are familiar with SAP technology we have also recently announced an ABAP based environment that is part of SAP cloud platform and that people can can use if they want to build applications. So that and this is where as I said the product marketing and product management folks wanted me to have this one single box that reads multi-cloud foundation and the messaging around that is essentially we as SAP cloud platform care for abstracting away all those low level things like what are the underlying infrastructures what are those complicated and sometimes crazily fast underlying technologies and we make sure that actually people on top can can do their things but before people can can do their things we also need to provide them with services. So using SAP cloud platform we provide a consistent set of services that are available on all those infrastructures can ideally be consumed from all those environments and then obviously there's people that are building their applications that are writing their functions that are writing own services on various layers be it on cloud foundry be directly on Kubernetes etc etc but then obviously you need to have an interconnection between the stuff that people write on the platform and those services and this is essentially where then the service manager kicks in because that's the piece that kind of intermediates between applications functions that want to consume a service and those services themselves. So with that that completes the picture of where we from the SAP side see the whole platform as a service ecosystem to be headed and as you see from that picture it's not only platform as a service it's also function as a service as well as container as a service and with that I think my time has been up two minutes ago I thank you very much if you're interested and excited about joining that journey we are in fact hiring pretty much globally so talk to to me talk to us if you want to join that effort and with that thank you very much for your attention