Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert

Serverless architecture

This brief is to demonstrate how one can leverage selected SAP BTP Kyma runtime serverless features.

This instalment covers:

  •  how to override a base function image

Requirements and Disclaimers:

Sample code:

Putting it all together.

SAP BTP, Kyma runtime is SAP's fully managed commercial kubernetes offering, part of SAP Business Technology Platform. It is often bundled with SAP Commerce Cloud and nowadays is becoming an extensibility runtime of choice.

Kyma brings additional modules on top of a kubernetes cluster. And serverless manager is one of them.

Good to know:

  • The serverless features described in this and following instalments can be used with both unmanaged OS Kyma on Gardener and SAP-managed SAP BTP, Kyma runtime.

Serverless Architecture

The serveless architecture is far from being trivial. Please study the diagram carefully.

Next, let's have a look at the Function's specification.

Seemingly, one of the coolest features with Kyma serverless CRD is the ability to override the base runtime image of a function.

This can be really useful when the default runtime image is just not good enough to accommodate some specific runtime dependencies.

However, please mind the gap. The kyma default base runtime function images are Alpine based. And Alpine based nodejs images have an extremely low count of security vulnerabilities;

Override function base image

For the sake of this brief, let's try it out with the nodejs16 functions. However, same approach is valid with any other supported serverless runtime, for instance with python 3.9.

In order to replace a default base image of a nodejs16 function we should try to understand how kyma does it.

Let's have a look at a Dockerfile definition used by kyma itself to create a function base image, namely:
# image base on 16.19.0-alpine3.17
FROM node@sha256:e427ffd1ba7915ca8d8aeba45806ef3f1f1e6b65ce152b363645cd7428f8d75a

ENV npm_config_cache /tmp/

RUN mkdir -p /usr/src/app
RUN mkdir -p /usr/src/app/lib
WORKDIR /usr/src/app

COPY package.json /usr/src/app/
RUN npm install && npm cache clean --force
COPY lib /usr/src/app/lib

COPY server.js /usr/src/app/server.js

CMD ["npm", "start"]


The build of the above Dockerfile will result in the following stock image, that eventually will be used in the function kaniko build

Good to know:

  • The docker files used in the function build are stored as config maps in a kyma cluster namespaces. Goto your cluster to look them up.

Building a custom image.

In order the build a custom image first you need to clone the project kyma github repository:
gh repo clone kyma-project/kyma
cd components/function-runtimes/nodejs16/
add your Dockerfile, build the custom image and push it
to an internet facing docker repository
cp Dockerfile Dockerfile.custom.nodejs16
nano Dockerfile.custom.nodejs16
edit your Dockerfile.custom.nodejs16 then save it
and build your custom image
docker build --platform amd64 -t <docker_id>/<docker_repo>:bullseye-slim16 -f ./Dockerfile.custom.nodejs16 .

You also need to make a decision about a new base nodejs16 image. That's an important decision as you are entirely liable/responsible for this choice and the custom image that will be built based upon it.

For the sake of this brief I have picked a public node:16.19.0-bullseye-slim as my new nodejs16 base image.

Next, you can create a custom function base image using a custom Dockerfile.custom.nodejs16 definition.

Last but not least, you shall need to publish the image to a public and internet facing docker repository.

For instance, let's say the new nodejs base image is node:16.19.0-bullseye-slim and that we are going to add a bunch of linux libraries to accommodate for any specific runtime dependencies, as follows:
FROM node:16.19.0-bullseye-slim

ENV npm_config_cache /tmp/

RUN mkdir -p /usr/src/app
RUN mkdir -p /usr/src/app/lib
WORKDIR /usr/src/app

COPY package.json /usr/src/app/
RUN npm install && npm cache clean --force

RUN apt-get update
RUN apt-get install -y openssl python make g++

COPY lib /usr/src/app/lib

COPY server.js /usr/src/app/server.js

CMD ["npm", "start"]


Let's build and then publish the custom image:

  • docker build --platform amd64 -t <docker_id>/<docker_repo>:bullseye-slim16 -f ./Dockerfile.custom.nodejs16 .

[+] Building 2.4s (16/16) FINISHED                                                                                                                                                                                          

=> [ 1/10] FROM 0.0s
=> CACHED [ 2/10] RUN mkdir -p /usr/src/app 0.0s
=> CACHED [ 3/10] RUN mkdir -p /usr/src/app/lib 0.0s
=> CACHED [ 4/10] WORKDIR /usr/src/app 0.0s
=> CACHED [ 5/10] COPY package.json /usr/src/app/ 0.0s
=> CACHED [ 6/10] RUN npm install && npm cache clean --force 0.0s
=> CACHED [ 7/10] RUN apt-get update 0.0s
=> CACHED [ 8/10] RUN apt-get install -y openssl python make g++ 0.0s
=> CACHED [ 9/10] COPY lib /usr/src/app/lib 0.0s
=> CACHED [10/10] COPY server.js /usr/src/app/server.js 0.0s
=> exporting to image 0.0s
=> => exporting layers 0.0s
=> => naming to<docker_id>/<docker_repo>:bullseye-slim16

Publishing the custom image:

  • docker push <docker_id>/<docker_repo>:bullseye-slim16

Eventually, this custom image can be used with kyma serverless nodejs16 functions definitions, for instance:
kind: Function
name: runtime-image-override
labels: runtime-image-override
annotations: {}
namespace: default
runtime: nodejs16
source: |-
module.exports = {
main: async function (event, context) {
const message = `Hello World`
+ ` from the Kyma Function ${context["function-name"]}`
+ ` running on ${context.runtime}!`;
return message;
runtimeImageOverride: <docker_id>/<docker_repo>:bullseye-slim16

Thus all is needed is adding spec.runtimeImageOverride to the function definition with the name of the custom image and applying the new definition.

Good to know:

  • in order to force the image change with an existing function the source code of this function may need to be touched/edited as well as to trigger the function build process.

  • unsupported base images with their Dockerfiles for either nodejs16 or nodejs14 can be looked up here.

  • a more thorough sample code that demonstrates  SAP HANA Cloud official nodejs driver from a function is available in this gist.


In the next instalment of this series I will demonstrate how to use standard sap libraries to access secrets mounted as volumes.

To help you get started there is a serverless code sample here.

Good to know:

Visual Studio Code

I hope you have enjoyed reading the blog post. Feel free to provide feedback in the comments section below.


SAP Community:

SAP Community Topic Page link:

SAP Community Q&A Tags:
Kyma Open Source:
SAP BTP, Kyma runtime:

Follow me in SAP Community: piotr.tesny