SAP Business Technology Platform (SAP BTP) environments constitute the platform-as-a-service (PaaS) offering on subaccount level with up to three runtimes to build cloud native applications. The SAP BTP Kyma environment offers a fully managed Kubernetes runtime to orchestrate cloud native serverless functions and containerized microservices.
Cloud Foundry and Kyma are cloud native runtimes of the SAP BTP Extension Suite, built on Kubernetes. Kubernetes offers container orchestration, with management and scaling capabilities, on infrastructure layers of hyperscaler cloud platforms like Microsoft Azure or Amazon AWS. Under the hood, Gardener abstracts SAP Kubernetes workloads on hyperscaler platforms to enable vendor agnostic developments with same operating experience everywhere.
Cloud Foundry on Kubernetes is built on the cloud native cf-for-k8s distribution with Istio as routing tier. EIRINI (as Diego substitution) enables Cloud Foundry to deploy for CAP (Cloud Application Programming) applications as pods (workloads) on Kubernetes.
The SAP BTP Multi-Cloud Foundation comprises Cloud Foundry, Kyma and ABAP environments with a multi-cloud compatibility for different cloud infrastructures.
The Kyma Runtime of the SAP Business Technology Platform Extension Suite is a fully managed kubernetes runtime, based on the open-source kyma-project. Kyma extends Kubernetes with a set of best-in-class tools and open-source projects like JetStream NATS for Eventing or Istio to handle microservice communication.
Kyma offers Serverless Computing and Microservice development to implement lightweight event-driven extensions or applications. Both options are suitable to implement data-driven business processes or to implement business logic to provision business data as OData services.
Kyma cloud native Microservice development supports any programming language, that can be containerized with certain access on infrastructure level. Kyma Functions are lightweight implementations based on the serverless engine with support of Node.js and Python programming languages.
Kyma is recommended for Function as a Service (FaaS) process extensions for SAP Digital Manufacturing Cloud (SAP DMC) and can be used with SAP BTP Extensibility Services for S/4HANA Cloud, Customer Experience, Marketing Cloud or SuccessFactors.
Kyma modules are independent developed components with functionality offered by custom resources and controllers which reconcile the desired state.
The following list provides information about Kyma modules:
Kubernetes (or k8s, where 8 replaces the 8 characters ubernete) is focused on container management and orchestration. K8s offers declarative configuration and monitoring of all kind of workloads in hybrid and multi cluster environments. Middleware services are available as pluggable components.
Kubernetes based Cloud Foundry and Kyma environments offer modern cloud technologies with different application implementation options. Serverless Kyma functions hide infrastructure components to enable application development with highly scalable workloads.
Cloud Foundry supports 12-factor-compliant application and stateless microservice developments with maximum degree of automation and buildpacks to enable bring your own language (BYOL) implementations. Cloud Foundry organizations are assigned 1:1 to subaccounts and ensure tenant isolation of business units with user and authorization management.
Multi-tenant applications on provider accounts can be published with the SaaS Provisioning service to multiple consumer accounts. The tenant isolation has to be implemented on application level by tenant ID.
The table below provides a high level comparison of selected Cloud Foundry and Kyma runtime features, which helps to find the best runtime for specific implementations.
| Features | Cloud Foundry | Kyma |
|---|---|---|
| Level of workload Isolation | Organizations | Namespaces |
| Development Flexibility | medium | high degree, pluggable operating and monitoring features |
| Availability of Backing Services | Service Broker | Service Broker, Kubernetes Operators |
| Microservice Development use cases | less complex "Nano" services | recommended approach for complex containerized solutions |
| Serverless Function support | not available | supported |
| Region assignment | on subaccount level | on subaccount level for runtime and on cluster level |
The Kyma runtime offers a high degree of flexibility to implement complex containerized serverless solutions.
There are various integration options available to connect SAP BTP and services on Hyperscaler platforms like SAP Cloud Integration or SAP Datasphere connectors, Private Link services, using SAP BTP Connectivity and Destination services, SAP managed Hyperscaler options for PostgresSQL and Redis.
Open Service Broker APIs (OSBAPI) and Kubernetes Operators are two popular approaches to integrate cloud native applications with backing services on multi-cloud environments. The SAP BTP Service Management in the Kyma Environment combines these two approaches two integrate SAP SaaS solutions deployed on Kubernetes clusters with service brokers on Hyperscaler environments.
Kubernetes environments enable multi-cloud integrations between SAP BTP and Hyperscaler platforms like Microsoft Azure, Amazon AWS and Google Cloud with the SAP BTP Service Manager.
The SAP BTP Service Manager acts as central registry and enables the consumption of hyperscaler cloud services with Kubernetes Operators.
Kubernetes operators allow to attach backing services to cloud native SAP BTP applications and operator patterns to define custom controller which act on Custom Resource Definitions (CRD). CRD metadata for packaging and development can be managed with the operator framework.
SAP Kyma offers the Free Tier option with 4 CPUs and 16 GB of RAM with around 33% of vCPU and 33% of memory for idle clusters without any customer workload. Kyma Free Tier is suitable to explore Kubernetes container orchestration of containerized workloads.
Kyma clusters with standard service plans can be deployed on Hyperscaler environments with commercial unit (so-called 'Node') of size 2vCPUs and 8GB RAM.
Subscription offerings of Hyperscalers like Azure, AWS or Google for managed Kubernetes are alternatives to SAP Kyma with attractive pricing options.
Azure Kubernetes Services (AKS) offers cluster autoscalers like HPA (Horizontal Pod autoscaler) triggered by internal metrics. KEDA (Kubernetes Event Driven Autoscaling) enables scaling with real-time metrica provided by various event sources like Azure Event Hub, Azure Application Insights, NATS JetStream or Apache Kafka and exposed to the AKS HPA by the KEDA Metrics server.
Kubernetes offers capabilities to orchestrate containers with workloads on multi-cloud environments and enables the multi cluster management with solutions like Azure Arc or SAP Gardener. Beyond that, cloud environments like Microsoft Azure, Amazon AWS and SAP BTP offer managed Kubernetes environments with the ability to move Kubernetes clusters from one provider to another to reduce vendor lock-in.
Kubernetes clusters are sets of nodes to run containerized applications controlled centralized with a control plane. Multi-cluster deployments enhance availability, isolation and scalability of applications.
The central control plane of Kubernetes enables global decisions about the cluster e.g. scheduling, as well as detecting and responding to cluster events. There are two primary communication paths from the control plane (apiserver) to the nodes. One from the control plane to the kubelet process and the second from the control plane to any node, pod or service through the apiserver's proxy functionality.
Kubernetes clusters are composed of different components. Kubelet is the primary node agent, which ensures that containers are running within pods. Pods are the smallest scheduling object, running on a node worker machine with containers sharing resources like storage or networking.
ReplicaSets are in charge of keeping a desired number of identical pods running in deployments which manage scale up and down operations.
Kubernetes offers ConfigMap for non-sensitive data and Secret objects to externalize configurations and sensitive information from applications. Secrets should be used for sensitive data like passwords or API keys. Separating sensitive from non-sensitive data allows to implement secure RBAC rules. ConfigMaps and Secrets can both be injected at runtime as environment variable into pods or mounted as volume for file access to pods.
Dapr Bearer Middleware and OAuth-Proxy2 reverse proxy are Kubernetes security solutions with OIDC authentication and OAuth authorization flow support. OpenID Connect (OIDC) is built on top of the OAuth2 authorization protocol and offers ID tokens with user information for authentication.
OAuth flows can be implemented as Authorization Code grant with user interaction or Client Credentials grant if access is requested by applications. The /oauth/authorize endpoint returns an access token for response_type=code and additionally an OIDC ID token with response_type=token to be used to get access or refresh tokens from /oauth/token endpoints. OIDC ID and OAuth access token (Opaque or JWT) are both bearer tokens which enable the access of client applications to resources on behalf of users.
Kubernetes secrets are objects to store confidential data like passwords, tokens or keys. To implement GitOps workflows with ArgoCD or Flux, secrets stored in Git repositories should be protected by encryption options like sealed secrets or SOPS.
Sealed secrets private and public keys are stored in the Kubernetes cluster of the sealed-secrets controller.
SOPS master keys can be stored in key management solutions like AWS KMS or Azure KeyVault.
The following command demonstrates the usage of SOPS with AWS KMS.
sops --encrypt --kms <arn> --encrypted-regex --in-place <filename>By default, Kubernetes secrets are stored unencrypted in the etcd data store. Encryption at rest or RBAC are options to implement enhanced security.
Kubernetes Role Based Access Control (RBAC) can be implemented with roles and bindings namespace or cluster specific. With RBAC, secrets can be protected as resources without read access.
Kubernetes GitOps solutions like Flux or Argo CD treat Git repositories as single source of truth for CI/CD workflows, with declaratively specified desired state of application and infrastructure (IaC). Flux and Argo CD use Custom Resource Definitions (CRDs), support the management applications, configuration and secrets with SOPS.
Kubernetes offers various extensibility options like for instance file configuration or API extensions with custom resources. Kubernetes custom resources define declarative APIs to manage custom objects like controllers or application configuration using Kubernetes tools.
Controller are Kubernetes API clients which read the .spec and update the .status of objects within Kubernetes clusters.
Kubernetes Operators are software extensions of the Kubernetes API with custom resources to manage applications and their components.
Multiple controllers for one application, specific application features can be handled.
Azure Service Operator (ASO), AWS Controllers for Kubernetes (ACK) and Google Cloud Config Connector handle collections of custom resources definitions with assigned controllers to enable the usage of Hyperscaler resources by applications deployed on Kubernetes clusters.
Custom Resource Definitions extend the Kubernetes API with dynamically registered resources which contain data without any logic implemented. Functionality to interact with the custom resources can be implemented with controllers or operators.
Kubectl offers commands to retrieve information about custom resources.
kubectl get crd <name> -o yamlIstio provides a uniform way to integrate microservices, manage traffic flows and policies. Istio can be combined with Knative and is part of the SAP Kyma environment.
Multi cluster service meshes connect, manage and secure communication between different parts of microservice architectures with replicated or shared control and data planes. Data planes are composed of intelligent Envoy proxies, deployed as sidecars for microservices within pods.
Another kind of Envoy proxy is running on the edge of a service mesh, integrated with Istio ingress gateways for traffic load balancing, monitoring and routing. Internal traffic control can be configured with Istio cluster local gateways.