Skip to Content
Product Information
Author's profile photo Joerg Singler

SAP Cloud Platform Extension Factory, serverless runtime is GA now!

First of all, I need to admit that it took a while to make the former beta version of SAP Cloud Platform Functions generally available. Due to the revised strategy of SAP Cloud Platform becoming the Business Technology Platform, we reshaped and optimized the former Functions beta service accordingly. Its rebranded name reflects the new priorities and focus of this service. In the context of the Extension Factory, the current and future focus of the serverless runtime now prioritizes the ease at which you can develop extensions with the convencience of fully-managed technology. In other words, less focus on general purpose functionality, and more focus on extensions to enable seamless integration with SAP business systems and processes.

Furthermore, this new service provides carefree entry for customizing and building functional extensions of business systems. This fully-managed serverless runtime provides our customers with the following advantages:

  • Lower costs, because customers pay for resource consumption, not idle times
  • Fully managed scaling and managment – SAP is responsible for scaling and managing the service based on the customer’s needs
  • Decreased development complexity – thanks to the focus of serverless runtime on extensions, developers don’t need to think about infrastructure-related topics such as connectivity or server bootstrapping and can focus instead on the required business logic for their extension.

The goal of SAP Cloud Platform Extension Factory, serverless runtime is to become the lightweight option for extending business systems similar to the extension spots in on-premise ABAP systems. Extensions are integrated with the standard business processes and systems, but are decoupled from the digital core. They allow customers to keep the core clean of custom code.

Importantly, customers are not locked in to the serverless runtime and can switch seamlessly to the upcoming managed Kyma runtime. Being based on the same aligned technology standards and concepts – a transition is possible without any changes having to be made to the application code. With that, a customer can switch to a more flexible approach and added freedom with the Kyma runtime, which also exposes the underlying Knative/Istio/Kubernetes layer. This however brings more responsibility in terms of costs and operations, as it adds dedicated infrastructure resources. The availability of the serverless runtime and the Kyma runtime bring maximum flexibility to our customers who can choose the approach that best suits their needs at a given time without risk of being locked in to either runtime for the duration.

For more information, see Cloud Platform Extension Factory, serverless runtime.




Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo tauming hew
      tauming hew

      According to SAP Help, it seems like S/4 business event is using SCP Enterprise Messaging service while C/4 is going with Kyma. Although SCP Enterprise Messaging service is parked under SCP Extension Factory, is there any particular reason why we can't just have a single place i.e. Kyma for all events, regardless or whether it is S/4 or C/4? Now, if I have both S/4 and C/4, I would need to subscribe to SCP Enterprise Messaging service and manage a Kyma/k8s cluster.

      Looking at the SAP Help for serverless runtime, it seems like I will still have to setup and pay for SCP Enterprise Messaging if I need to listen to S/4 business events. Is there any reason why I can't register a function directly to a particular S/4 or C/4 event without going through the trouble of setting up SCP Enterprise Messaging or Kyma? Just like how function works in hyperscaler where I can just register to listen events for a particular service in most cases.

      Author's profile photo Joerg Singler
      Joerg Singler
      Blog Post Author


      all the events will be available at a single place mid-term and you will be able to trigger functions in the serverless runtime or on kyma, but also applications deployed on CloudFoundry or on Abap in the Cloud aka Steampunk. So there is a central place to get all events from and there is freedom of choice how you want to consume events in Cloud Platform.

      Regarding hyperscaler services, also on the hyperscalers you need to connect the publisher such as S/4 of an event and the consumer of an event e.g. a serverless function using a messaging service in order to have a guaranteed message delivery and a proper patterns such as pub/sub-distribution of events. So this is best-practise and SAP's approach is not different.

      Hope this helps.

      Best, Joerg