Hello and welcome everyone, 

Lately, with my colleague Martin Frick, we have ported our sample multitenant application from SAP BTP Cloud Foundry Runtime to SAP BTP Kyma Runtime. After this journey, we thought of sharing our experiences in both runtimes in a comparative manner to help the community members that are interested in developing cloud solutions on SAP Business Technology Platform. 

As a developer or architect, choosing the right platform for your application is crucial for its success. With the increasing popularity of cloud-based solutions and extensions on SAP ecosystem, many developers are developing on SAP BTP Runtimes, such as SAP BTP Cloud Foundry Runtime (CF) and SAP BTP Kyma Runtime (Kyma). In this blog post, we will take a closer look at the similarities and differences between these two platforms, as well as the experiences of developing application on each. 

1. What is SAP BTP Cloud Foundry – SAP BTP Kyma Runtime? 

SAP BTP Cloud Foundry is an SAP platform as a service (PaaS) offering that enables you to deploy and operate your applications in the cloud. It is built on the open-source Cloud Foundry platform, which offers a full runtime environment for deploying, running, and scaling applications. Cloud Foundry keeps implementation specifics hidden. That is why Cloud Foundry refers to applications rather than containers. It abstracts away the complexity inside the platform, showing a simpler, more straightforward interface with a lower barrier of entry for users. 

On the other hand, Kyma is built on top of Kubernetes, which is the de-facto standard to deploy and operate containerized applications as of today. The goal of Kyma according to official documentation is: “SAP BTP Kyma Runtime is an application runtime that provides you a flexible and easy way to connect, extend, and customize your applications in the cloud-native world of Kubernetes.” SAP BTP Kyma Runtime has the full power of Kubernetes and open-source components on top of it to simplify enterprise application development in the SAP BTP ecosystem. Therefore, it comes with flexibility and power.  

2. Application Deployment

Application Containerization 

Cloud Foundry runtime has the ability of container abstraction. Developers can deploy their applications without having to containerize it (themselves). The built-in buildpack concept understands the type of application from the content and creates the application runtime for you. For example, if you have a Node.js project, having a package.json file in your project directory serves as a signal for the Cloud Foundry Buildpack to interpret. This makes of course developers’ life extremely easy. But still, developers might use Docker images and deploy to Cloud Foundry in case there is a strong requirement to do so, but I would not recommend it. Buildpacks should be always the first choice unless there is a strong requirement as said before. 
 
Since Kyma Runtime is running on top of Kubernetes, any application must be containerized before deploying it. SAP recommends using Paketo buildpacks images or SAP official images to containerize your applications. If you create your own images, all the security aspects of that image are your responsibility. But if you use Paketo buildpacks or SAP official images, chances of having security issues are minimized since most of the security updates comes from the providers of those images. 

 Deployment & Release Management Tools 

In Cloud Foundry runtime, today’s one of the main tool for application deployment and release management is MTA CF plugin. It is commonly used and adopted by many SAP customers and partners. The whole idea of MTA is managing the applications and their dependent resources in a declarative manner. Working with descriptor file of Multiapps plug-in (mta.yaml) can be found here. And I found this SAP Samples repository useful while constructing mta.yaml files for deployment.  

In Kyma Runtime, the tool which serves to same purpose is Helm. Helm is a package manager for Kubernetes that allows you to easily deploy, manage, and share applications and services.  

Helm usage and concepts are different from the MTA-CF plugin. Helm has a larger and more diverse open-source community, while MTA-CF plugin has a more focused community around the Cloud Foundry runtime. Helm’s learning curve is quite steep at the beginning, but after grasping an understanding, it is extremely powerful. In addition, Helm has a rich documentation and sample content on the internet. My colleague Maximilian Streifeneder also covers this topic on his blog post.  

Stage Management 

Stage management is a critical aspect of software development, and it involves managing the different stages or environments of a software project, from development to testing to production. I can imagine that the readers of this blog post are familiar with DEV, QA, PROD style stage management from ABAP Systems.

In Cloud Foundry projects, stage management in a similar fashion can be achieved with SAP Cloud Transport Management Service. In this case, the multitarget application (mta) can be transferred across different Cloud Foundry environments. I will refer here to the official documentation of the SAP Cloud Transport Management service to give a concrete example: “A developer of an application or of SAP Cloud content artifacts can trigger the transport of changes in a development subaccount, while the resulting import into the test and production subaccounts is handled by a central operations team.” 

On the Kyma side, developers can use Helm to have a comparable approach for stage management. create three separate Kubernetes namespaces for each stage of the development cycle, and use Helm charts to manage deployment to each environment. Configure the Helm chart to use different values files for each environment, and use Helm to install the application in each environment using the appropriate values file. For example, you can create a values-dev.yaml file for the development environment, a values-int.yaml file for the integration environment, and a values-prod.yaml file for the production environment.  

3. Application Development

In this section, you will be reading the application development experiences on both runtimes. 

Development Frameworks and Languages 

Cloud Foundry runtime has pre-installed buildpacks for you for certain popular languages and frameworks such as Java, Node.js, Python and Go. By default, these are the languages and frameworks need to be chosen to be able to make use of buildpacks concept. With this approach, as mentioned on Application Deployment section, it is extremely easy to deploy an application on Cloud Foundry runtime. That is the whole idea of Cloud Foundry, entry level barrier is significantly lower. In addition, it is essential to bring up a crucial point. SAP currently officially supports buildpacks for Java, Python, and Node.js. Other buildpacks available on Cloud Foundry are developed by the community and use at your own risk. 

Kyma Runtime on the other hand, can run any framework or language which can be containerized. After the containerization of the application, you need to create all the dependent Kubernetes & Kyma resources such as services, pods, API Rules and so on, by using the package manager Helm or plain K8s deployment files. And if you are not familiar with the fundamental K8s concepts and Helm, you might expect a higher barrier of entry on Kyma Runtime compared to Cloud Foundry runtime. But please also note that Kubernetes has a larger and more active community than Cloud Foundry, with a wealth of documentation, tutorials, and resources available for learning.

SAP CAP (Cloud Application Programming Model) Support

SAP CAP (Cloud Application Programming model) is a framework for building cloud-based business applications using Node.js and Java. Therefore, there is no doubt that it will run seamlessly on both Cloud Foundry and Kyma Runtime. SAP CAP is a proven framework for increasing developer productivity in enterprise application context with lowering the overhead you usually must implement by yourself, and already highly adopted by customers and partners of SAP. 

SAP CAP has built-in commands for creating your deployment files which are mentioned in the previous section. Thus, your Helm charts or your MTA deployment file will be generated for you automatically, which is quite helpful. Relevant guidance can be found here for Kyma and here for Cloud Foundry. 

4. Service Management and Consumption

Service management and consumption is always a critical part of application development. You will always need to use some backing services from your underlying infrastructure to be able to fulfil your application’s tasks.   

Service Consumption from SAP Business Technology Platform (BTP)  

Cloud Foundry runtime is very well integrated with many SAP BTP services, therefore consuming a backing service, and managing its lifecycle is quite easy with the help of Service Brokers. Developers just create a service definition in their MTA deployment file (or in SAP BTP cockpit) and bind it to their applications. Then the backing service credentials are automatically delegated to the VCAP_SERVICES environment variable. Also, deprovisioning the service instance and service bindings are quite straightforward. This blog post from DJ Adams makes a great deep dive on service brokers and service consumption on Cloud Foundry. 

Also, in Kyma Runtime, service management and consumption are built on top of the same idea. Kyma Runtime comes with its service management and the consumption capabilities work in a similar way but a different implementation with the help of the SAP BTP Service Operator. For developers and architects out there it is safe to say the service consumption experience is remarkably similar. Implementation details are of course a bit different, while Cloud Foundry uses the environment variables, in Kyma Runtime each service binding is a K8s secret, and these secrets must be attached to the application using volume mounts.

This blog post demonstrates service consumption in SAP BTP Kyma Runtime.  

Service Consumption from Hyperscalers 

Sometimes, you might need to consume and manage service instances from your hyperscaler account such as AWS (Amazon Web Services), Microsoft Azure, GCP (Google Cloud Platform).  

For an application running in Cloud Foundry runtime, the relevant hyperscaler service is usually consumed via the User Provided Services concept of Cloud Foundry. Developers create their own service instances in the relevant hyperscaler account, then with the credentials, a user provided service instance can be created and bound to the application. The downside of this approach is that it is not possible to manage your service life cycle from the Cloud Foundry directly. The operations like service creation, deletion, configuration must be handled manually by using the relevant hyperscaler account. 

In Kyma Runtime, hyperscaler service consumption is more elegant. Hyperscalers have Kubernetes operators which are designed to ease the consumption and management of services from any cluster. As a result, application developers can install the relevant Kubernetes operator, and then consume the hyperscaler service while creating a Kubernetes object. Therefore, the service lifecycle can be managed like any other K8s object, without needing to go through the steps in the relevant hyperscaler account to manage it. In addition to that benefit, since the hyperscaler service is now managed by a Kubernetes operator and the corresponding resources in the cluster, nothing blocks you from adding those pieces of information into your application set of Helm resources or to add a fresh one to bootstrap empty clusters fully automated. This blog post gives a good overview about the usage of Kubernetes Operators from Kyma. And here is the documentation of AWS Controllers for Kubernetes (ACK) as an example.

In addition to Kubernetes Operators provided by hyperscalers, Crossplane is also worth mentioning. Crossplane is a multi-cloud control plane which you can deal with multiple infrastructure providers. This is really interesting especially when you want to connect to different backing services from different hyperscalers from the same application on Kyma runtime. If you want to understand how Crossplane differs from hyperscaler provided k8s operators, I would recommend to read this blog.

Service Consumption & Integration with SAP Systems  

Both systems have great connection options to SAP Systems running in all kinds of infrastructure.  

This repository from my colleague Max, demonstrates the connection to S/4HANA on-premises both from Kyma and CF. 

This official documentation explains extending SAP Success Factors. 

5. Platform Extensibility 

As mentioned in the previous sections, Cloud Foundry runtime hides the implementation details of the underlying infrastructure from the developers with its opinionated approach. The main goal of Cloud Foundry is just to reduce the entry barrier for the developer to get to a running application. This comes with limited amount of extensibility since developers cannot change much on the platform itself. The approach you will take with Cloud Foundry is more like; “Hey, run this for me please, I do not care how.” 

In Kyma, this is different from Cloud Foundry. Kubernetes (K8s) by its design, provides a very extensible architecture. Since Kyma Runtime is running on top of K8s, it also has this extensible architecture. Application developers have much more power on Kyma Runtime. The approach with Kyma can be described as; “Hey, run this for me please, I tell you precisely how it should look like.” 

6. Service Mesh 

Nowadays, it is possible to deploy so many applications / services into your infrastructure. After a certain amount of time, it becomes crucial to manage traffic, authentication, authorization across your services and applications. Service Mesh is the answer of to this problem. 

Currently in Cloud Foundry runtime, there is no service mesh solution. 

On the other hand, Kyma Runtime comes with Istio. Istio is an open-source service mesh which is adopted by an enormous number of users. Istio is powerful and gives you a lot of control over your cluster. For example, by default in Kyma Runtime service-to-service communication is not encrypted. With Istio, it is just a matter of seconds to configure mTLS across your service-to-service communication and then all data will be encrypted. In short, if it is needed to deploy the services with a “zero trust” mindset, Istio helps a lot.  

The second point worth mentioning are the powerful traffic management capabilities of Istio. Istio includes a mighty set of features for managing traffic, including load balancing, routing, and service-level security policies. 

Also, Istio observability provides a comprehensive set of tools that allows you to gain insights into the behaviour of your microservices and the Istio service mesh and troubleshoot issues when they occur. 

7. Multitenancy

From an architectural point of view, having a multitenant application is remarkably similar in both the Kyma runtime and the Cloud Foundry runtime, because multitenancy is a SAP BTP concept that is abstracted from the runtimes.

The difference is not the multitenancy but the containerization, security, deployment on these runtimes. The overall architecture is similar but the touchpoints between your multitenant application and the underlying infrastructure are different.  

As an example, in Cloud Foundry you open your approuter to the internet via using CF Routes, the corresponding component in Kyma Runtime is API Rule. The way they work is the same, but the way you expose your endpoints to internet is of course different.  

If you are interested in developing multitenant applications on SAP BTP, I would strongly recommend that you check these repositories. They are very well documented and ready-to-use! 

• Multitenant application sample repository on CF 
• Multitenant application sample repository on Kyma 

8. Good-To-Know

Custom Domain 

In SAP CF Runtime, you must use SAP Custom Domain Service to be able to have a custom domain.
In SAP Kyma Runtime, you do not need to use SAP Custom Domain Service, you can bring your own domain, and use that as you like. 

SAP Continuous Integration and Delivery 

SAP Continuous Integration and Delivery is very well integrated with SAP BTP Cloud Foundry runtime. Worked seamlessly for our use case. 

While SAP recommends using Paketo buildpacks, which offer a streamlined way to package and deploy microservices, it is important to note that SAP CI/CD Service currently has built-in support for Dockerfiles, but not for Paketo buildpacks. You can of course still make use of the SAP CI/CD Service using your own Docker files to containerize your applications.  

PostgreSQL on SAP BTP – Hyperscaler Option 

In some cases, you may need an additional relational database in addition to SAP HANA Cloud. SAP Business Technology Platform (BTP) provides a PostgreSQL Hyperscaler option for users who need a managed relational database. It is important to note that this backing service, as of today, is only available for use with Cloud Foundry, and not with Kyma runtime. Of course, Kyma support will also be there eventually, but until that you have following two options: 

1. Using PostgreSQL offerings directly from hyperscalers with the help of Kubernetes Operators as previously mentioned on the blog post. 

1. Host your own PostgreSQL database, which can be complex and time-consuming to set up and manage. This option is not recommended, as it can be more expensive and difficult to optimize for your application’s needs. 

9. What to choose?

SAP Cloud Foundry runtime and SAP Kyma Runtime are two runtimes to develop cloud-native application, each with its own set of advantages and disadvantages. 

SAP Cloud Foundry Runtime may be a good option if you are looking for a PaaS solution that provides a consistent developer experience and supports multiple languages and frameworks. Also, SAP Cloud Foundry Runtime is designed to provide a quick and straightforward way to deploy and manage applications, which can help reduce the time to market. If you want to just deploy your application without knowing the details of underlying infrastructure this is for sure a good option. This opinionated approach of SAP Cloud Foundry by design eases the pain, but it of course limits the customization and flexibility of the runtime. 

SAP Kyma Runtime might be an excellent choice for customers and partners who has requirements that requires interaction with underlying infrastructure. For instance, with SAP Kyma Runtime, it is super easy to manage the accessibility of your microservices with Istio or K8s Network Policies. Or you can create custom load balancing options via using Destination Rules of Istio. This type of configurations currently not possible with SAP Cloud Foundry. SAP Kyma Runtime is much more powerful than SAP Cloud Foundry in terms of flexibility and infrastructure management.  

When making the choice, you should also consider your application architecture and team skill set.

Important: Availability of services for the runtime you are interested in should not be a selection criterion for you at the start of developing your project. SAP BTP is a service–oriented platform. SAP BTP backing services will eventually be available for all SAP BTP runtimes. It is crucial to keep this also in mind during the decision process.

Conclusion

In this blog post, my colleague. Martin Frick and I tried to share as much as possible from our own experiences we gathered during our journey on Kyma with you, and we hope that this blog post will help you with choosing your runtime. 

Both runtimes are not superior to the other. I have personally experienced it as two different runtimes designed for diverse needs. It would not be surprising for me if I see both runtimes being used together. 

If you have any experiences with these runtimes, I would like to ask you to share them in the comments section of this blog post. Feel free to follow my partner in crime Martin Frick, and me for the upcoming adventures! 

Do you want to start and experience yourself? Again, I would like to remind you of these two repositories. 

Sustainable SaaS Application on SAP Cloud Foundry
Sustainable SaaS Application on Kyma

Further Readings

• Cloud Foundry – K8s a Deeper Comparison 
• Custom Domains with Kyma
• Istio Service Mesh
• Helm Official Documentation