Hello Friends,
Welcome back to my blog!
SAP has been projecting BTP (Business Technology Platform) for a while now and has been trying to turn it into a leader in the PaaS space. As a result, a lot of organisations globally have adopted SAP BTP and the adoption rate continues to grow especially among the already existing SAP customers.
As you might know, SAP BTP offers different types of services. One of the most commonly used services in BTP is application development. And that is where SAP Cloud Foundry, SAP Neo and SAP Kyma come into the picture.
In this blog, we are going to discuss what is SAP Cloud Foundry, SAP Neo and SAP Kyma and the difference between them.
If you are interested in learning about the basics of SAP BTP, then please check out my previous blog here.
Getting back to the topic, firstly, what is SAP Cloud Foundry?
Cloud Foundry is an open-source platform that is governed by Cloud Foundry Foundation. It is not proprietary to SAP; anyone can download it and use it for free in their own infrastructure. SAP BTP also provides Cloud Foundry as a service and to use it will cost you money because it is hosted on SAP BTP and you need to pay for the service provided by SAP. Cloud Foundry is offered as a service by so many other cloud providers as well like Amazon Web Services, MS Azure, GCP, IBM, etc.
So now the question is, what is the purpose of Cloud Foundry? You can use cloud foundry to build, deploy and run applications that are built using different programming languages.
Before Cloud Foundry, if you have to build multiple applications, you need to first install different types of runtimes, code editors, development kits, databases, integrations, authentication, etc. It was complex and developers were spending a lot of time on administration tasks instead of concentrating on developing applications.
But Cloud Foundry offers runtimes, business services, programming languages, libraries and services all in one place. So, the developers can concentrate on coding while the admin tasks are taken care of by the Cloud Foundry.
Cloud Foundry supports different types of programming languages like Java, Node.js, Go, PHP, Python, .NET Core and Staticfile.
It can be hosted on its own internal infrastructure or on cloud infrastructure offered by companies like Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform, OpenStack, etc.
Now, in the SAP context, developers can use the Cloud Foundry runtime service in SAP BTP to build new applications or extend functionalities of an existing SAP on-premise or Cloud application. They can use the API library offered by BTP to integrate their applications with SAP and non-SAP applications.
SAP BTP Neo runtime service:
SAP Neo is also a runtime service available in SAP BTP, similar to Cloud Foundry, but was developed by SAP and it is not open source.
Using Neo, developers can create HTML5, Java and SAP HANA extended application services (SAP HANA XS). It doesn’t allow a “bring your own language” offering as Cloud Foundry does and it can only be hosted on SAP infrastructure and not others. The types of programming language one can use in Neo is also limited. Hence when compared, Cloud Foundry is a better runtime environment for developers to build their applications. SAP is also phasing out the Neo environment, so we can safely say the future is Cloud Foundry.
Difference between SAP Cloud Foundry and SAP Neo
| SAP Cloud Foundry | SAP Neo | |
| Programming languages that are supported | Java, Node.js, Go, PHP, Python, .NET Core and Staticfile. | HTML5, Java and SAP HANA extended application services (SAP HANA XS) |
| Bring your own programming language. | On-premise or on any cloud infrastructure | Only on SAP infrastructure |
| Hosting | Yes | No |
| Open Source | Yes | SAP Proprietary |
What is SAP Kyma?
If we need to talk about Kyma, then first we need to talk about Kubernetes and containers.
So, let’s go backwards and start with the container first.
Traditional deployment era:
Sometime back, when the container concept was not available, businesses used physical servers to run their applications. In a physical server, there’s no mechanism to define the resource boundaries for the apps, which led to problems with resource allocation. For instance, if numerous apps are running on a physical server, there may be times when one application uses up the majority of the resources, which lowers the performance of the other applications. Running each application on a different physical server would be a fix for this. However, due to resource underutilization and the high cost of maintaining numerous physical servers, this could not scale.
Virtualized deployment era:
Later on, virtualization was introduced as a fix. It enables you to utilise the CPU of a single physical server to operate numerous Virtual Machines (VMs). Because the information of one application cannot be freely accessible by another application, virtualization enables applications to be segregated between VMs and offers a level of security.
Applications can be added or changed simply, hardware costs are decreased, and virtualization improves resource usage on physical servers and scalability. A group of physical resources can be displayed as a collection of reusable virtual computers thanks to virtualization.
On top of the virtualized hardware, each VM functions as a complete machine running all of its parts, including its own operating system. So, there was still some level of complexity involved as the applications that are developed on a VM were tied to the operating system the VM is running on.
Container deployment:
Then comes the container era. While containers and virtual machines (VMs) are similar, the OS can be shared among the apps thanks to their flexible isolation rules. Containers are therefore seen as lightweight and less complex to run when compared to VMs. Similar to a VM, a container has its own filesystem, the share of CPU, memory, process space, and more. As they are decoupled from the underlying infrastructure, they are portable across clouds and OS distributions.
Containers have become popular because they provide these extra benefits.
What is Kubernetes?
Applications can be bundled and run effectively using containers. You must manage the containers that run the applications in a production environment to prevent downtime. For instance, another container needs to start if one goes down. Wouldn’t it be simpler if software handled this behaviour?
You have a framework to execute distributed systems robustly thanks to Kubernetes. It handles application scaling and failover, offers deployment patterns, and more.
Now back to Kyma. SAP BTP Kyma is a fully managed Kubernetes runtime that is based on an open-source project.
We now know that containers can help build and run applications on any platform. If there are multiple containers, then Kubernetes can help manage those containers to provide scalability and failover services.
But what if the applications inside the containers need to communicate with other applications in the outside world? That is where Kyma comes into the picture. It is an extra integration tissue on top of the Kubernetes that helps us do both, expose the APIs from the containers so that external applications can integrate and as well as allows the applications inside the containers to consume APIs and events from other applications.
On top of facilitating integration, It also provides additional services like security, monitoring, and tracing.
To summarise,
- You build software applications using either Cloud Foundry or SAP Neo
- The applications you built can be placed inside a container or multiple containers
- Containers are managed by Kubernetes runtime
- Kyma provides an additional integration layer on top of Kubernetes that allows your apps inside the containers to integrate with the outside world
Please check out my YouTube channel as well and if you have any questions, please leave a comment and I will respond to you.
P.S. Check out my course on Udemy – “Introduction to SAP – The Complete Package for Beginners“
A blog about SAP 