Deploy serverless components on SAP BTP, Kyma runtime

[mangeshpise]

The approach to break-down large monolithic applications into meaningful functional capabilities (a.k.a. microservices) is not native to modern cloud-native developers (pun intended). However, when it comes to the deployment strategies for these microservices, there is a wide spectrum of architecture patterns, akin to the wide variety of platforms & technologies on which they can be deployed (Richardson, 2016). One such pattern of deployment leverages modern cloud platform capabilities called "Serverless". As the name suggests, server-less provides a direct interface for application developers to deploy their application code on cloud infrastructure without having to care about setting up infrastructure in a traditional sense. Of course, the platform service providers have built the necessary infrastructure and tooling that enables such a rapid deployment.

Kyma is a platform provided by SAP Business Technology Platform (SAP BTP) that enables developers to deploy their application components as serverless". In my last blog post, we already took Kyma through a challenge to deploy an existing containerized Kubernetes-managed workload on SAP BTP, Kyma runtime. In this blog post, you will find how the same Kyma runtime also extends to allow running serverless components of your distributed applications.

Example Use Case

I believe that it is efficient to learn by means of an example. Also, because the objective is deliberately focused only on understanding the deployment of serverless components of a distributed application, the example needs to be simple and easy to follow.

Background

XYZ Inc. is a fictitious company that provides special lawn care products and receives orders from various ordering channels (viz. website, mobile, customer service, etc.). Customers agree to a tentative service date during the ordering process. Because XYZ uses special formulations and needs specific equipment, their product can only be applied in specific weather conditions, viz. it must not rain for at least 24 hours after application, and must therefore be applied by their trained field staff. Thanks to the digital transformation mindset at XYZ, they have already enabled their field service staff with a mobile app to manage and track daily service appointments. At the start of the day, each field service representative checks out their daily schedule and makes a determination based on onsite weather conditions that the service can be conducted. If it cannot be conducted, they must connect the customer with a customer service representative who would reschedule the appointment. This takes much time from the field service representative who could have otherwise covered a larger territory.

Introducing Serverless

The software engineering team at XYZ's IT department has proposed modifications to the field representative's mobile app to include the following capabilities:

• The daily schedule listing would be able to check real-time weather conditions within the listing. This would save an unwarranted onsite trip.


• In case of unacceptable weather, they would initiate a workflow to notify the customer service representative that the service needs to be rescheduled with the customer.

Assuming the entire field service management is a microservice deployed on SAP BTP, the software engineering team decides to deploy this new feature as a serverless component instead of modifying and redeploying the microservice. They considered the following benefits of this approach:

1. An agile approach to validate the functionality in the field without making larger upfront modifications to the microservice.


2. Quick turnaround as the software engineering teams focus solely on the feature development without getting wrapped around infrastructure topics such as sizing, provisioning, and monitoring. Note: Platforms providing serverless capabilities usually manage auto-scalability and provide out-of-the-box monitoring.


3. Cost savings from the inherent nature of the serverless pricing models where cost is usually dependent upon total compute runtime and micro compute sizes against constantly running optimally-sized infrastructure.


4. Pave a path for Event Driven Architecture (not in the scope of this blog post) as serverless functions can be triggered to execute based on events in contrast to invoking APIs via a UI or batch executions.


5. The polyglot programming paradigm is continued within serverless deployments further allowing developers to choose the appropriate programming language for the identified function. For example, within a microservice-oriented application written in NodeJS and Java, a Python-based serverless function can be easily deployed to take the advantage of feature-rich machine-learning libraries mostly available in Python.

Serverless Building Blocks in Kyma

As mentioned earlier, serverless allows application developers to focus on the application development first and directly interact with the platform (SAP BTP, Kyma runtime) to deploy their application, specifically the function. Since Kyma runtime is based on Kubernetes, we can leverage a combination of standard Kubernetes resources and the custom resources provided by Kyma, which takes advantage of various Kubernetes tools to deploy standardized builds and speed up the overall development process.

As far as serverless functions are concerned, Kyma provides functions.serverless.kyma-project.io CRD, which is at the core, but we will see all the other building blocks essential in deploying serverless components on Kyma. Refer to Fig.1 as we describe each of these elements.

Fig. 1. Serverless Building Blocks in SAP BTP, Kyma runtime

 

1. Code

Kyma supports NodeJS (releases 14 and 16) and Python (releases 3.9). In this example, we will be using NodeJS. If starting from scratch, one can initiate a new nodejs project from within an empty directory using npm as below.

$ npm init 

package name: (code) fn_reschedule_service

version: (1.0.0) 

description: Reschedules lawn application service

entry point: (index.js) handler.js

test command: 

git repository: 

keywords: 

author: Mangesh Pise <m.pise@sap.com>

license: (ISC) 

About to write to /<path>/serverless/package.json:



{

  "name": "fn_reschedule_service",

  "version": "1.0.0",

  "description": "Reschedules lawn application service",

  "main": "handler.js",

  "directories": {

    "test": "test"

  },

  "scripts": {

    "test": "echo \"Error: no test specified\" && exit 1"

  },

  "author": "Mangesh Pise <m.pise@sap.com>",

  "license": "ISC"

}



Is this OK? (yes) yes 

Note that the entry point must be handler.js, which is defined as a nodejs module and must contain a function named main as shown below. The main the function takes two parameters - event and context.

module.exports = {

  main: (event, context) => {

    // ...

  }

}

At this point, you are free to install any other nodejs libraries and require them in handler.js. For example -

$ npm install axios --save

which updates the dependencies in the package.json file and allows you to use it in your application code as below -

const axios = require('axios');

module.exports = {

  main: (event, context) => {

    // ...

    // <code here>

    // ...

  }

}

2. Code Repository

Kyma has the ability to pull your code from a code repository. In this example, we will push our code to a GitHub repository and shortly see how Kyma can be notified to pull the code from there. I am going to make an assumption that you are capable of creating a GitHub repository and pushing your code there.

3. K8's Resources Definitions

Kubernetes, being an orchestration platform, needs information on the desired states of the containers, say, the contract between the application developer and the underlying platform. Kubernetes ensures the desired state by managing the cluster components, such as the number of pods, config parameters, storage, memory, etc. This contract/definition of cluster components (a.k.a. resources) is provided to Kubernetes' control plane via Resource Definition files. In addition to many standard resource definitions, such as Namespaces, Pods, Services, Volumes, etc., Kubernetes can also be extended to support Custom Resource Definitions (CRD). This makes Kubernetes modular and extendable.

Kyma provides multiple CRDs that further simplify the deployment of containerized workloads on Kubernetes. Function is one such Kyma CRD that simplifies deploying serverless applications on SAP-managed Kubernetes clusters on SAP BTP. This is the crux of SAP BTP, Kyma runtime.

With that background, in our hypothetical application, we will be writing at least three kinds of Resource Definitions so Kyma can deploy and manage our application as a serverless application.

Note: All of these definitions can be stored in single or separate .yml files.

Secret

In the simplest sense, this secret definition will hold the credentials for the GitHub repository from where the function will receive the latest application code. This is a standard Kubernetes resource.

Note: values must be encoded as base64.

apiVersion: v1

kind: Secret

# -----------------

type: Opaque

metadata:

  name: github-secret

data:

  username: Z2l0aHViQHVzZXJuYW1lLmhlcmUK==

  password: Z2l0aHViLnBhc3N3b3JkLmhlcmUK=

Function

This is a Kyma CRD (notice the apiVersion) that will pull the latest application code from the specified GitHub repository in the specified branch (see source).

We have specified here that the application name is ping, and the source code is provided from a gitRepository. In addition, we also have the ability to set environment variables that will be accessible within the pod, specified under env. Notice that the environment variables themselves can be acquired from other Secrets.

apiVersion: serverless.kyma-project.io/v1alpha2

kind: Function

# -----------------

metadata:

  name: ping

  labels:

    app.kubernetes.io/name: ping

spec:

  runtime: "nodejs14"

  source:

    gitRepository:

      url: "https://github.com/<path>/<repository>.git"

      baseDir: "/<path>/ping/"

      reference: "main"

      auth:

        type: "basic"

        secretName: "github-secret"

  env:

    - name: CREDSTORE_URL

      valueFrom:

        secretKeyRef:

          name: credstore

          key: url

APIRule

When the serverless function is deployed on Kyma, it is allocated an IP address that is accessible only internally within the Kubernetes cluster. Other Kubernetes resources, such as events, can access and invoke these functions, which is a completely viable architecture option if event-driven architecture (EDA) is the goal. However, if the goal is to expose API endpoints that invoke serverless functions, an additional Kyma object, called APIRule, needs to be defined as below.

apiVersion: gateway.kyma-project.io/v1beta1

kind: APIRule

# -----------------

metadata:

  name: ping

  labels:

    app.kubernetes.io/name: ping

spec:

  service:

    name: ping

    port: 80

  host: ping.<subdomain>.kyma.ondemand.com

  rules:

    - path: /.*

      methods:

        - GET

        - POST

        - DELETE

        - PUT

        - OPTIONS

      accessStrategies:

        - handler: allow

  gateway: kyma-gateway.kyma-system.svc.cluster.local

 

4. Deployment

The final stage of this process is to deploy one or more .yml files created in Step 3. In this case, we will assume there is a single .yml file.

Prepare a connection to SAP BTP, Kyma runtime -

# Setting up KUBECONFIG for Kyma on SAP BTP

export KUBECONFIG=~/<path to extracted code>/kubeconfig.yaml

Deploy all the resources defined in Step 3 -

# Create all the resources

kubectl apply -f /<path to extracted code>/deployment.yml

secret/github-secret created

function.serverless.kyma-project.io/ping created

apirule.gateway.kyma-project.io/ping created

As you can notice from the response of the kubectl command, our secret, function, and apirule are all deployed on the cluster.

You may now validate this from the Kyma dashboard that can be invoked at the URL, https://dashboard.kyma.cloud.sap > Namespace default > Select Workloads in the left menu > Select Functions > Select ping.

Fig. 2. Serverless Function ping running on SAP BTP, Kyma runtime

 

The function's endpoint can be obtained from the Configuration tab.

Conclusion

Kyma has extended the Kubernetes platform via custom resource definition (functions.serverless.kyma-project.io) to enable going serverless with minimal effort. Although this blog post covers only the basics of deploying Functions on SAP BTP, Kyma runtime, full power of this platform comes to visibility when combined with other Kyma capabilities such as APIRule, the in-built NATS Eventing framework, and Grafana-based monitoring visualizations. The beauty is that all these components are already plumbed into the Kyma runtime elevating developer experience for faster innovation cycles.

Have you leveraged serverless in your enterprise? If so, I urge you to share your experiences, use-cases, and best practices; but more importantly, learn more about SAP BTP, Kyma runtime on SAP Community.

 

---

References:

Richardson. (2016, February 10). Deploying Microservices: Choosing a Strategy. NGINX. Retrieved March 4, 2023, from https://www.nginx.com/blog/deploying-microservices/

Pise. (2022, December 19). How to relocate an existing app running on your Kubernetes Cluster to Kyma on SAP Business Technology Platform. SAP Community Blogs. Retrieved March 5, 2023, from https://blogs.sap.com/2022/12/19/how-to-relocate-an-existing-app-running-on-your-kubernetes-cluster-...