Tell us what you think

We want to create the best possible experience for our learners. Your feedback helps us to improve the experience for everyone.

Working with Serverless Functions

Objectives

After completing this lesson, you will be able to:

Describe briefly the serverless functions
Identify appropriate situations for using serverless functions
Use different ways to invoke a serverless function
Create a serverless function

Serverless Functions Overview

What are Serverless Functions?

A Serverless Function is a workload type that is provided by the project "Kyma" through a custom resource (CR). "Serverless" implies no server or infrastructure is involved. But that's wrong. It simply means that a third party manages the server, and you do not have to worry about it. You can focus on the code of your Function.

Technically, Functions in Kyma rely on multiple Kubernetes resources such as Deployments, Services, HorizontalPodAutoscalers, and Jobs.

So in terms of Serverless Functions in Kyma, you can run code snippets without providing and maintaining the container image or the infrastructure. And like deployments based on containers, Functions can also be scaled, exposed and subscribed to events.

Pros and Cons of Serverless Functions

Click on the "Pro" and "Con" buttons to find out more.

Invoking Serverless Functions

Functions can be invoked in different ways. The following table shows the different ways to invoke a Function:

Ways to invoke a Function

Invocation Method	Description
HTTP	An HTTP request invokes the Function. The endpoint must be exposed first.
Event	The Function is invoked by an event.

The following image illustrates how the function is invoked by an Event:

An event-driven architecture within a Kubernetes cluster using Kyma. It shows an Event Publisher sending events to a Proxy, which forwards them to an Event Controller that triggers a Serverless Function.

Creating Serverless Functions

You can create a Function by declaring a Function manifest in YAML or using Kyma dashboard's visual editor. The visual editor will generate the Function manifest for you

Describing a Function Manifest

With Kyma, you can create Functions in Node.js and Python. Kyma extends Kubernetes with a custom resource (CR) for this workload type.

A function manifest (version v1alhpa2) in YAML for a simple hello world example might look like this:

Code Snippet

1234567891011121314151617181920212223242526272829
apiVersion: serverless.kyma-project.io/v1alpha2
kind: Function
metadata:
  name: hello-kyma-function
  labels:
    app: hello-kyma-function
spec:
  runtime: nodejs20
  source:
    inline:
      dependencies: |
        {
          "name": "hello-kyma-function",
          "version": "1.0.0",
          "dependencies": {}
         }
      source: |-
       module.exports = {
           main: async function (event, context) {
             const message = `Hello ` + process.env.NAME
                + ` from the Kyma Function ${context["function-name"]}`
                + ` running on ${context.runtime}!`;
             console.log(message);
             return message;
         } 
        } 
  env:
    - name: NAME
      value: "Kyma"

Note

As you can see above, the ${context["function-name"]}is a runtime variable that is injected by Kyma. It contains the name of the Function. This is an example of the vendor lock-in, that we mentioned earlier. Using such components makes your code less portable.

The following table shows the different fields of the manifest:

Fields of the manifest

Field	Description
apiVersion	The version of the custom resource.
kind	The kind of the custom resource.
metadata	The metadata of the custom resource.
spec	The specification of the custom resource

Let's break down the spec part of the manifest:

Spec part of the manifest

Field	Description	Possible Values
spec.runtime	The runtime of the Function.	nodejs20, python39
spec.source	The specification of the Function.	inline, gitRepository
spec.source.source	The source code of the Function.
spec.source.dependencies	The dependencies of the Function.
spec.env	The environment variables of the Function.

To get a full list of the fields, see the Function CR documentation. There are many more fields that you can use to configure scaling, resources, gitRepository and many more.

Summary

Serverless Functions are a good choice if you want to run less code, for example, to process data or respond to events. You can split your microservice into smaller Functions if you're going to scale it differently. Functions also support the event-driven architecture and ensure quick deployments of your code. However, you have to consider that Functions are vendor-specific and that you are limited to the supported runtime environments of Kyma.