Skip to Content
Technical Articles
Author's profile photo Uwe Klinger

CAP on Kyma – Deploy your CAP apps to SAP BTP, Kyma Runtime

With the latest CAP major release 6 for cds and cds-dk, you can deploy your CAP application on the Kyma Runtime of SAP Business Technology Platform (SAP BTP). The Kyma Runtime is the SAP-managed offering for the Kubernetes based Kyma cloud-native application runtime.

Scope

For the first release of CAP on Kyma, our goal was to support “extension” projects:

  • Single-tenant CAP service (Node.js / Java)
  • SAP HANA database
  • SAP Fiori elements or SAPUI5 freestyle UIs
  • Authentication based on XSUAA
  • Connectivity to cloud and on-premise systems

As usual, we went beyond the pure technical enablement: we wanted to make it as easy as possible for you to get your application on the Kyma Runtime.

But let’s start with the technical enablement, the runtime stuff.

Runtime Needs

The runtime support was not a big deal. As CAP applications run on your local machine and on Cloud Foundry, why shouldn’t it be possible to run them in another environment like Kyma? There must be a Node.js or Java execution environment for sure. But this is easy to achieve with containers. Differences are in the interaction between platform and applications.

An important aspect is how applications get access to external services, such as the SAP BTP services.

In the environment variable VCAP_SERVICES, Cloud Foundry provides service bindings as JSON to applications. This mechanism exists neither in Kubernetes nor in Kyma. Service credentials are stored in secrets and can be injected into environment variables or into the file system of an application.

We thought that it would be good to have something that might allow interoperation with non-SAP BTP services as well. Ideally, an open standard. We’ve chosen servicebindings.io, which is closest. Read more about it in the blog post The new way to consume Service Bindings on Kyma Runtime.

Deployment

Once we had ensured that CAP runs and could access SAP BTP services, we started looking for a good deployment experience. Deployment on Kyma – and on Kubernetes in general – includes the following tasks:

  1. Build container images for your application
  2. Push container images to a container registry
  3. Apply Kubernetes resources for your application (using the pushed container images)

 

(Source: CAP documentation → Deploy to Kyma/K8s)

 

Containerize Your Application

SAP recommends Cloud Native Buildpacks, such as provided by the Paketo Buildpacks to build container images. You might wonder if this really is the way to do it, everyone seems to use Dockerfiles. That’s true, but buildpacks have some convincing benefits that make your life easier.

As a prerequisite, you need to install the docker (or docker compatible) and the pack tools.

You can create a container image for your service with a pack command like this:

pack build $CONTAINER_REGISTRY/cpapp-srv --path gen/srv \
    --buildpack gcr.io/paketo-buildpacks/nodejs \
    --builder paketobuildpacks/builder:base

No Dockerfile needed!

The buildpack approach was already followed by Heroku and Cloud Foundry, but things are done in a different place:

  • Cloud Foundry: cf push uploads your application files to the staging service within the Cloud Foundry cluster. The staging service builds the container image and stores it in Cloud Foundry’s built-in registry.
  • On the Kyma Runtime, this process happens out-of-cluster. First, you build the container image and second, you upload it to some container registry. Unfortunately, SAP has no such offering.

You have the choice between various cloud and self-hosted container registry offerings available. You just need to make sure it is secure and reliably accessible from the Kyma cluster.

Play the Kubernetes API

Everything that runs or happens on Kubernetes is described with resource files. They are formatted as YAML files, but JSON is possible as well.

Example:

busybox-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
    name: busybox
spec:
    containers:
    - name: busybox
      image: busybox
    args:
    - sleep
    - "3600"

Kubernetes kubectl command line lets you bring this resource into your cluster:

kubectl apply -f busybox-pod.yaml

Under the hood, this sends a request to the Kubernetes API that checks the resource and activates it in the cluster. An operator watching for changes picks it up and brings it to live.

With the Pod resource, you run a single container image that executes the waits for an hour and terminates after that.

The image is downloaded from the specified container registry. By default, Docker Hub is used if no registry is specified. In this example, only the image name busybox is provided.

So, once your service’s container image is available in the container registry, you can apply the resource files for your application.

There are different ways to structure and apply resource files. Our choice is Helm.

The CAP Helm Chart

Helm allowed us to create a set of reusable and configurable deployment files for CAP applications. See section Customize Helm chart in the CAP documentation for more details. With the CAP tooling installed, you can add the Helm chart to your project by just running cds add helm.

The Helm chart contains all the required Kubernetes resources for deploying your application, SAP HANA database content and HTML5 applications, as well as creating instances of SAP BTP services and consuming them.

You can even update the Helm chart later with another run of cds add helm.

The configuration of the Helm chart is stored in the chart/values.yaml file. cds add helm creates this file with defaults based on your CAP project’s configuration. The content is similarly structured like an mta.yaml file.

Let’s have a brief look at the Kubernetes resources provided by the Helm chart:

Your service gets into action using a Kubernetes Deployment resource. This resource supports having multiple instances of the same service and has zero-downtime upgrade built-in. The SAP HANA and HTML5 deployments are done using Jobs. Don’t search for them after successfully installing the Helm chart. They get cleaned-up if everything worked well.

Using SAP BTP Services

You might wonder how to create SAP BTP service instances from Kyma. Let me take you to a short journey to the past: In former times, the SAP BTP services were registered in the Service Broker of Cloud Foundry landscapes. But SAP has already freed the services from the Cloud Foundry chains. Nowadays, services are registered in the SAP Service Manager that isn’t limited to Cloud Foundry. You can connect a Kyma Runtime – or in general any Kubernetes – cluster with an SAP BTP subaccount. The SAP BTP Service Operator in your Kyma cluster does the connection to the SAP Service Manager. It is automatically installed and configured by enabling the Kyma Runtime.

The SAP BTP Service Operator has custom resource definitions for creating service instances and service bindings. Service bindings create secrets that are injected into the applications’ pods. I’ve already explained that.

Example:

apiVersion: services.cloud.sap.com/v1alpha1
kind: ServiceInstance
metadata:
  name: cpapp-xsuaa
spec:
  serviceOfferingName: xsuaa
  servicePlanName: application
apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
  name: cpapp-srv-auth
spec:
  serviceInstanceName: cpapp-xsuaa

This creates a secret containing the credentials in the cluster:

kubectl get secrets
NAME            TYPE
cpapp-srv-auth  Opaque

The CAP Helm chart lets you configure your required services without the need to write these files.

But even without deploying your application, you can test with those Kubernetes provisioned SAP BTP services. As you can do for Cloud Foundry, you can connect your local application to them using cds bind. Just add the --on k8s option.

For example:

cds bind --to cpapp-srv-auth --on k8s

Now, you can run your application with the real XSUAA instance. For example, with CAP Node.js:

cds watch --profile hybrid

Why Kyma Runtime?

So, that’s all nice and good, but why should I bother about Kyma Runtime?

Kubernetes is a mature cloud platform with convincing concepts and functionality built-in. But even more important, it is the de-facto industry standard for running containerized workloads. It has a huge and vibrant ecosystem.

The Kyma Project adds service mesh, serverless, eventing, and observability functionality on top of it by using established open source technology.

SAP provides you with a managed offering of all of that embedded in the SAP BTP. You just need to click on Enable ;-).

Added Value on Top of Kubernetes: The Service Mesh

Services meshes are good examples how Kubernetes extensions can add value. Istio is a service mesh that builds on Kubernetes and is included in Kyma. It’s a programmable, secure network within your Kubernetes cluster.

For example, you can use it to secure the communication between services. Let’s say you have a shopping application, which consists of a Bookshop and an Order service, and you want to ensure that the Order service can only be called from Bookshop. With Istio that’s possible with some configuration – you guess it: resource YAML files. No programming required!

The Bookshop just calls http://order/.... Istio injects sidecar containers that run side-by-side with your applications’ containers, and take over the external communication for them. By that, the HTTP request from Order is sent through a mTLS tunnel and for the Order service it ensures that it accepts only requests from Bookshop. Istio generates and distributes the required certificates automatically. You don’t need to care for that.

Try it Yourself

You can learn how to deploy a CAP application with the Deploy Your CAP Application on SAP BTP Kyma Runtime tutorials, which are part of the SAP BTP end-to-end tutorial series.

If you’re new to CAP, you should create the tutorial application from scratch with the Build an Application End-to-End Using CAP, Node.js and VS Code tutorial mission:

  1. Prepare Your Development Environment for CAP
  2. Create a CAP Application and SAP Fiori UI

Alternatively, you can start with the prepared application from the cap-roles branch of the tutorial’s examples repository.

Learn More

You will find more information in the new Deploy to Kyma/K8s guide as part of the revamped Deployment Cookbook in the official CAP documentation “capire”.

Examples

Further, CAP samples have been extended for Kyma deployment:

The End

That’s it. I hope you’ve enjoyed reading this blog. I’m looking forward to hearing from you about your first hands-on experience with CAP on the Kyma Runtime.

Assigned Tags

      5 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Helmut Tammen
      Helmut Tammen

      Hi Uwe,

      thank you for this blog post.

      You stated that currently only single tenant apps are possible. Will and if yes when will multitenancy be possible? 

      Regards Helmut

      Author's profile photo Uwe Klinger
      Uwe Klinger
      Blog Post Author

      Hi Helmut,

      You can build multi tenancy applications on Kyma Runtime. It works the same way like it works for CF. See the CAP Multi tenancy Cookbook for general CAP multi tenancy documentation.

      However, we do not yet have support in our Helm chart. That means you need to add the required Kubernetes resources, such as the SaaS registry and the Service Manager instance, yourself. You can just put them into the chart folder along with the templates provided by "cds add helm". We consider to add it with one of our next relases.

      One important remark wrt. Service Manager. You need to create the Service Manager "container" instance in CF. Otherwise you won't be able to create HDI container instances.

      There are a few resources on multi tenancy on Kyma available. For example:

      I haven't reviewed them, but I would assume that they provide good guidance.

      Best regards,

      Uwe

      Author's profile photo Helmut Tammen
      Helmut Tammen

      Hi Uwe,

      thanks for the valueable answer. Good to know that there is already a solution and you work on further simplicity.

      Best regards
      Helmut

      Author's profile photo Mustafa Bensan
      Mustafa Bensan

      Hi Uwe,

      In the context of this blog post, does it mean SAP is moving away from Cloud Foundry in general and specifically for CAP?  Does SAP intend to stop support for applications deployed to BTP Cloud Foundry in future?

      Thanks,

      Mustafa.

      Author's profile photo Jens Huesken
      Jens Huesken

      Hello Mustafa,

      Thanks for this great question. We are not moving away from Cloud Foundry and do not stop support for applications deployed to SAP BTP, Cloud Foundry runtime.

      As we evolve Kyma as a K8s-based runtime along our unified runtime strategy, it is of equal importance to support CAP on Kyma as a first-class citizen in multi-cloud.

      The Cloud Foundry runtime and the Cloud Foundry based services will not go away. The Cloud Foundry based services are planned to be made consumable in Kyma as well, so that customers have full flexibility.

      Best regards,
      Jens