Hello, everybody, welcome to TechEd! My name is Jan Schaffner, I'm the head of the Foundational Plane of the Business Technology Platform. And today, I want to talk to you about our unified runtime strategy. And that's essentially about where we see the future of our runtimes in the Business Technology Platform heading towards. Let's frame this in the context of the Intelligent Enterprise. As you know, the Intelligent Enterprise gives you the opportunity to get the most out of your SAP applications by them being integrated via SAP on the Business Technology Platform, which powers the Intelligent Enterprise. And the Foundational Plane with its runtimes, which we cover today, is the place where you write that glue that extend the LoB applications to really deliver that intelligence that gives you this integrated promise.
Let's frame the problem a little bit. What are the goals that we want to accomplish as we think about a new runtime strategy? The first goal is certainly to keep your investments protected. This means whatever we change in terms of strategy will be incremental, taking into account that you are where you are on Neo and on Cloud Foundry. We want to make sure that you continue to get the most benefit out of these investments that you have already made into SAP. The second point is: We want to move to a point where the runtimes become less important, but the services become more important in the sense that services are consumable regardless of the runtime you are in.
And we'll get into some more detail around that. That facilitates real runtime flexibility, including also - if that's something you want to do - consuming SAP properties from, let's say, a Lambda runtime in AWS. And of course, you're more than welcome to leverage all the great tooling that we provide to make life easier for you. And finally, for me a key point is to give you the full choice of runtime. By choice of runtime, I mean you can also change this later. You want to deploy something in a public hyperscaler now, and later you want to move to an SAP-operated data center, maybe in a region where there is no public hyperscaler support - that will be possible.
OK, let's look at where we are starting from. One of our runtimes, the BTP Neo environment, is something we do not consider strategic anymore, which is something we've been talking about for a while. This means, it is currently not possible to net new onboard into the Neo environment. It is possible to renew existing subscriptions. But over time, we have the plan to actually sunset the Neo environment, as you know it.
We haven't set the date for this, because what we want to get right first, is a path forward for the applications that you have on Neo today. Because we don't want to overburden you with migration steps and re-platforming, which to some extent is a problem which we face today. As we have been telling you, that Cloud Foundry is the target, and that everyone should be migrating from Neo to Cloud Foundry.
We are adjusting our message here, where we said to you previously: 'Leverage the migration packs that we have in place and get on that journey of re-platforming.' But, we have a new idea for Neo, which I will explain in a second. Before that, let's briefly cover where we are with our Cloud Foundry environment.
Cloud Foundry is strategic for us. Which means it's still growing in terms of regions. We currently have eighteen regions, both in public hyperscaler clouds, also in regulated environments, but also on Alibaba Cloud in China. And it'll grow, and based on demand, we will add new regions here. And if you're happy with that environment, then by all means, stay in that environment and leverage Cloud Foundry going forward. However, Cloud Foundry is limited to running on hyperscalers.
The ones that we support are AWS, Azure, Google, and Ali. And currently, there are no plans to bring this into an SAP data center. So, what do you do, if you want to run in an SAP data center? Enter our unified runtime environment.
Again, the previous message was, migrate from Neo to Cloud Foundry. However we acknowledge, hearing your feedback, that this is a significant effort which is sometimes hard to justify to your business, because at the end of the day you are re-enacting a capability that you already have. But you have to go through basically learning new concepts, new programming paradigms, and in some cases also using other services, which is something we believe now, we need to make easier for you. Instead what we're doing is, we're creating a new place for innovation, because - besides investment protection - customers also want us to innovate and, you know, want SAP to partake in where the community is going, for example with Kubernetes and containers, and bring that innovation to you for your application development.
So, we are taking the BTP Kyma runtime as a starting point, which went generally available last year in May. And we are broadening that offering into what we call the unified runtime. So, this unified runtime is fully based on Kubernetes.
And it allows us to run it both on hyperscalers and in SAP data centers, not only the one or the other. That's the first interesting part, where you will get more flexibility from the strategy. Kubernetes as the underlay, and Kyma as the set of open-source tools that we build and make enterprise-ready on top for you, give you the benefits of higher automation, being able to leverage cloud-native paradigms, such as Buildpacks.io more natively, benefit easier from elastic scaling, or other features which are coming upwards from this new infrastructure paradigm. And generally, it gets you in a more ready state as the world moves to cloud-native technologies. But what is going on with the existing applications that you have on Neo? So, one thing which we are doubling down on is adding compatibility in this unified runtime for existing Neo applications.
The idea is to move these applications from Neo into unified runtime without changing the code. I have some more details on this in one of the next slides, but the main idea is to benefit from this tooling in the sense that it will save you the work of migrating this application. And for Cloud Foundry - as I said, it's strategic - we will keep this environment next to the unified runtime. As I said, it will be growing. So, there is no need to port applications from Cloud Foundry onto unified runtime. But if you have an existing Cloud Foundry app that you would like to run at some point in time in an SAP data center, for example, then what you can do is basically leverage the compatibility environment which we're building for that.
Which will essentially center around cloud-native Buildpacks. The code will also stay in place. Let's say, instead of an MTA YAML file, you'll be editing a Dockerfile. But other than that, it'll be very close. Talking about Neo compatibility in more detail: One thing I already mentioned is one guardrail we want to achieve is to lift an application and run it without changing the code.
We will also keep operational interfaces functional, and with that I mean mostly command line interfaces and other tools. We will support the Java and Java Enterprise application stereotypes, as well as HANA XS classic applications in this compatibility layer. This is really the types of applications for which we want to achieve this goal. And as you bring an application then from Neo into the Neo compatibility layer on unified runtime, you will be able to then, over time at your own pace, access other services which are part of our multi-cloud service portfolio. Then you can get more benefit from leveraging other services that we build at SAP, for example to integrate master data or to interface with LoB applications easier for application programming, as you evolve this application then over time.
For that purpose, we'll also automate service lookups so that we can keep this promise of keeping the code changes to a bare minimum. You'll also benefit indirectly from these cloud-native practices because, at the end of the day, this application will then run on Kubernetes as well. What about a Cloud Foundry application that you want to bring over to unified runtime? How do we do this? What we take as a starting point are cloud-native Buildpacks. You can check this out if you go to Buildpacks.io. This is what we take as the starting point that will make these enterprise-ready and give you 24/7 supported SAP-specific Buildpacks to run your SAP-specific workload.
As we do that, we apply a lot of best practices. We're also bringing the CAP environment into unified runtime. And also the tooling will be mirrored. For something like 'cf push', there will be an equivalent in unified runtime as well to give you the same lifecycle experience. And here again, the two benefits on the right are the same as if you port a Neo application to unified runtime. They have access to all the services in the portfolio, no matter if it's a service in the Cloud Foundry landscape or a native Kubernetes service, and also the benefit from cloud-native practices.
We are also under the covers, re-platforming some of our multi-cloud services to run on Kubernetes directly to make them more resilient, provide more stability, and availability, and elasticity. This is essentially how we tend to innovate by providing a Kubernetes-based runtime, but by doing so in an incremental fashion that doesn't deprecate any of the existing properties that we have, in the sense that your application code lives on, and that you can continue to run these applications. Speaking about the services cross-consumability topic in more detail: As I said, we want to make the runtimes actually less important. Who knows, what the next runtime will be in five years. There are no plans, but essentially, it should be possible to always evolve incrementally because the platform, at the end of the day, should render a set of services that you use to build an application to enhance an SAP application.
It should be a toolbox, where you also can change the runtime environment in the middle of the project, if you like. If it turns out you want to do some parts in Cloud Foundry, some parts in Kyma, or vice versa - or change this decision in the middle of a project, it will not matter because the same set of services will be available. What do I mean by that? We will not have a situation as we have in Neo versus Cloud Foundry, where for example, we have CPI in Neo and CPI in Cloud Foundry and there are feature disparities. We will move to a state, where we have a single service of each kind, and it will be consumable in all the runtimes.
In most cases, the starting point for this target service will be the service version as we have it in the multi-cloud environment. This cross-consumability will facilitate that flexibility, and this is something tangible, which we already started. So, if you look at the service scope of the Business Technology Platform, you will notice that over 60% of all services are already cross-consumable today. This means from within Kyma, for example, you can use the Audit Log service even though it's a Cloud Foundry service, and things of that nature. So, this flexibility is there, and we will complete the scope to 100% in the first half of the next year, for example with HANA Cloud being cross-consumable at the end of the first quarter next year already.
Summarizing my main points: We want to protect your investments into Neo applications, also in Cloud Foundry applications and services that you have built, while at the same time bringing new innovation with the Kubernetes-based application runtime, which will be - in the future - the center of BTP's runtime offering. It's called unified runtime, and it is based on Kyma. Kyma is an open-source project launched by SAP, which many customers also use on-premise to manage Kubernetes applications. We transformed it last year into a managed service offering in the BTP. We will bring it onto SAP data centers and public cloud infrastructures by using SAP Gardener as the infrastructure abstraction to basically go through these various infrastructures. It will take us some time to do this.
We will provide compatibility packs to run existing new applications as-is on unified runtime, so that at some point, while we work with you on what this experience looks like, then we'll deactivate Neo. Whereas you'll always have the choice between staying on Cloud Foundry versus developing natively in the Kubernetes world. And this choice will be supported by service cross-consumability, which will get us to a state, where we have a single service for each purpose, which you can use from any runtime. You will also be able to do parts of your project using hyperscaler-native runtimes, like AWS Lambda, for example. But if you use unified runtime, you will be able to change your choice of infrastructure at any time.
Also after deploying, you can re-deploy from a public hyperscaler into an SAP data center and vice versa, or add new regions. We don't have a concrete roadmap to share at this point in time, when, what region will become available both for hyperscalers and SAP data centers, but we will keep you posted. And, we wanted to share the strategy of how these runtimes will converge, because it's an important realization for us to provide you with that innovation capability, while being non-disruptive to where you are deployed with the technology you use today. There are several things that you can already check out today, because it's not all just strategy and far-out.
But as I said, the SAP BTP Kyma runtime is GA since last May. You can try it out, you can read up the documentation. We also have brought the cloud application programming model -CAP- onto the Kyma runtime. That's also something you can check out. You can also look at the Kyma project in its open-source project form, see if it's interesting to operate some of your Kubernetes workloads around SAP on-premise, if you like.
You can also go to Buildpacks.io and familiarize yourself with cloud-native Buildpacks, see how close this experience is to what you know from Cloud Foundry Buildpacks that you see on the platform. With respect to Neo application compatibility, you can check out our XSK repository. It's also technology that we start as an open-source project, but XSK is something we will turn into an enterprise-grade service offering, which will give you this new application compatibility in unified runtime. And in order for us to get it right, we need your help. Please reach out to me or my colleagues to help us understand where the challenges are with the applications you have on Neo for example, and what way they are unique.
And then we can help you figure out the right path to move this application from Neo to unified runtime. And we can make sure that our compatibility tooling, such as XSK, has everything that customers need to make that transition as painlessly as possible. So, please get in touch either by reaching out directly to me or through your SAP representatives. All right folks, here are more learning opportunities from SAP for you to check out. With that, I'm at the end of my presentation.
And thank you very much for tuning in. I hope this was interesting for you. Have a great TechEd. Goodbye.
[MUSIC PLAYING]
2022-04-11