What Kyma Runtime Is and Why Teams Use It on SAP BTP

Explanation

Kyma Runtime is a managed Kubernetes-based environment offered as part of SAP BTP. It is built on open-source Kyma, which itself is layered on top of vanilla Kubernetes with additional components for API exposure, eventing, service management, and observability. SAP operates the underlying cluster infrastructure so consultants and developers focus on deploying workloads rather than managing nodes, etcd, or the Kubernetes control plane itself. The business purpose of Kyma Runtime is to give organizations a standards-based, container-native platform for building extensions to SAP S/4HANA, SuccessFactors, or other SAP and non-SAP systems, without being locked into a single buildpack-based model like Cloud Foundry. Because Kyma runs arbitrary container images, teams can use any language, framework, or library, which matters when a project needs something Cloud Foundry buildpacks do not support well, such as a specific version of a machine learning library, a custom base image with compliance-mandated packages, or a sidecar pattern. Within BTP, Kyma Runtime is provisioned per subaccount as an environment, similar to how Cloud Foundry is provisioned as an environment. A subaccount can have a Kyma environment enabled through entitlements and quota assignment at the global account level. Once enabled, SAP provisions a dedicated Kyma cluster (or in earlier setups, a shared cluster, depending on the plan and region) tied to that subaccount. Each Kyma cluster maps roughly to one subaccount, which is an important governance boundary: workloads, secrets, and namespaces in one subaccount's Kyma cluster are isolated from another subaccount's cluster. A newcomer should understand the relationship between four layers: the global account (commercial contract and entitlements), the subaccount (a logical boundary for a specific project, environment stage such as dev/test/prod, or team), the Kyma environment instance (the actual cluster provisioned for that subaccount), and namespaces within that cluster (logical subdivisions for workloads, similar to folders). Consultants coming from an ABAP or Cloud Foundry background need to adjust their mental model: instead of deploying an application via cf push, you build a container image, push it to a registry, and apply Kubernetes manifests or Helm charts describing Deployments, Services, and APIRules. Kyma adds SAP-specific and Kyma-specific custom resources on top of raw Kubernetes, most notably APIRule (for exposing services externally through a managed Istio-based gateway with authentication), Subscription (for event-driven integration with the SAP Event Mesh or other event backends), and Service Instance/Service Binding resources (for consuming BTP services like Destination or Connectivity service from within the cluster, aligned with the Service Catalog/Service Binding open standards used by the Kubernetes ecosystem). Why this matters for integration work: many BTP integration scenarios need custom logic that Integration Suite's standard iFlow capabilities cannot express directly, such as custom protocol translation, heavy computation, or a bespoke event router. Kyma Runtime is the natural place to host that logic as a microservice, which then integrates with Cloud Connector, Destination service, and Event Mesh to reach on-premise or cloud systems securely. A critical point of uncertainty to flag: exact cluster sizing, node pool behavior, and whether clusters are single-tenant or multi-tenant can vary by region and commercial plan, and SAP has evolved this over time. Consultants should always verify current behavior in the specific subaccount's Kyma dashboard rather than assuming behavior from an older project.

Code example

# Example: minimal Kubernetes Deployment + Service to run in a Kyma namespaceapiVersion: apps/v1kind: Deploymentmetadata:  name: hello-integration-service  namespace: dev-team-aspec:  replicas: 2  selector:    matchLabels:      app: hello-integration-service  template:    metadata:      labels:        app: hello-integration-service    spec:      containers:        - name: hello-integration-service          image: my-registry.example.com/hello-integration-service:1.0.0          ports:            - containerPort: 8080          resources:            requests:              memory: "128Mi"              cpu: "100m"            limits:              memory: "256Mi"              cpu: "250m"---apiVersion: v1kind: Servicemetadata:  name: hello-integration-service  namespace: dev-team-aspec:  selector:    app: hello-integration-service  ports:    - port: 80      targetPort: 8080

Real project scenario

A retail customer needed a custom microservice to reconcile order data between a non-SAP e-commerce platform and S/4HANA Cloud before it reached Integration Suite iFlows, because the transformation logic involved iterative lookups against a third-party pricing API that were awkward to express in standard mapping steps. The team provisioned a Kyma environment in a dedicated integration subaccount, built a lightweight Node.js service as a container image, deployed it with a Deployment and Service, and exposed it internally so an iFlow could call it via HTTP before continuing the standard integration flow into S/4HANA.

Common mistakes

• Assuming Kyma Runtime works like Cloud Foundry cf push instead of requiring a container image and Kubernetes manifests or Helm charts. • Treating one Kyma cluster as shared safely across unrelated projects without understanding the subaccount-to-cluster mapping. • Not checking entitlement and quota limits before assuming Kyma can be enabled on a subaccount immediately. • Deploying workloads to the default namespace instead of creating project-specific namespaces for isolation and easier cleanup. • Ignoring resource requests/limits, leading to noisy-neighbor issues or evicted pods under cluster resource pressure.

Best practices

• Use separate namespaces per team, application, or environment stage within a Kyma cluster for isolation and access control. • Verify entitlements and quota for the Kyma environment at the global account level before promising delivery timelines. • Always define resource requests and limits on deployments to avoid uncontrolled resource consumption. • Store container images in a registry with proper access controls and image scanning before deploying to Kyma. • Confirm current cluster provisioning behavior (dedicated vs shared, sizing) directly in the BTP cockpit rather than relying on outdated assumptions.

Interview angle

Interviewers often ask candidates to explain the difference between Cloud Foundry and Kyma environments on BTP and when to choose each. A strong answer distinguishes buildpack-based, opinionated PaaS deployment (Cloud Foundry) from container-native, Kubernetes-based flexibility (Kyma), and ties the choice to concrete technical constraints like custom runtimes, sidecars, or specific eventing needs rather than just saying 'Kyma is newer.'