Runtime Environments and Connectivity: Cloud Foundry, Kyma, and Cloud Connector

Explanation

Once a subaccount exists with the right entitlements, the next foundational decision is which runtime environment will host custom code, integration middleware components, or extension applications. SAP BTP offers two primary environments for building and running applications: Cloud Foundry and Kyma. Choosing between them - or using both in different subaccounts - is a decision every BTP integration architect must be able to justify. Cloud Foundry is a Platform-as-a-Service (PaaS) model. Developers push applications (buildpacks for Java, Node.js, Python, etc.) and bind them to managed services (Destination, Connectivity, XSUAA for authentication, HANA Cloud, etc.) using a service broker model. Cloud Foundry abstracts away infrastructure concerns - there is no direct container/pod management - making it a good fit for teams that want to deploy business logic quickly without deep Kubernetes expertise. Many SAP-delivered capabilities, including parts of Integration Suite's underlying architecture and various extension scenarios, have historically been built on or alongside Cloud Foundry space and org constructs (an 'org' contains 'spaces', which contain applications and service instances). Kyma is SAP's managed Kubernetes environment, giving developers direct access to Kubernetes primitives (pods, deployments, services, and importantly, Kyma-specific extensions like Application Connector for exposing external APIs, Service Mesh for traffic management, and event-based integration via the Kyma eventing layer). Kyma is the preferred choice when a project needs containerized microservices, event-driven architectures, or fine-grained control over scaling, networking, or side-car patterns that Cloud Foundry does not expose. It requires more Kubernetes-specific skill on the team but offers greater flexibility for complex extension scenarios, especially those extending S/4HANA Cloud through the 'in-app' and 'side-by-side' extensibility models where side-by-side extensions often target Kyma. Regardless of environment choice, connecting BTP to an on-premise landscape (an ECC or S/4HANA on-premise system behind a corporate firewall) requires the Cloud Connector. Cloud Connector is a lightweight on-premise agent installed within the customer's network that establishes a secure, outbound-only tunnel to a specific BTP subaccount. It does not require inbound firewall rules, which is a major security advantage: the on-premise system never exposes a public endpoint. Within Cloud Connector, administrators expose specific backend system resource paths (not entire systems) as accessible resources, following a principle of least exposure. On the BTP side, a Destination is configured pointing to the appropriate Cloud Connector location and virtual host, and applications (or Integration Suite flows) reference this destination rather than hardcoding the backend URL, allowing environment-specific routing without code changes. The Connectivity service and Destination service work together in Cloud Foundry-based applications: the Destination service stores connection metadata (URL, authentication type, proxy type - Internet or OnPremise), while the Connectivity service handles the actual proxying of on-premise-bound calls through Cloud Connector. In Kyma, similar patterns exist but are often implemented via the Kyma Application Connector or via destinations consumed through the same underlying Destination service, since Kyma workloads can also bind to classic BTP services. Troubleshooting connectivity issues typically starts by isolating where the failure occurs: authentication failure at the destination (wrong credentials or expired certificate), Cloud Connector tunnel down (checked via the Cloud Connector administration UI, which shows connection status per subaccount), access control list restrictions on the backend resource path in Cloud Connector, or network-level issues on the customer's on-premise firewall. A methodical consultant checks Cloud Connector status first, then destination configuration, then backend system logs, rather than guessing. Security-wise, principal propagation (passing the end user's identity through to the backend rather than a technical user) is a more advanced but increasingly required pattern for compliance-sensitive scenarios, requiring certificate-based trust configuration between BTP and the backend ABAP system.

Code example

# Example: BTP destination configuration (conceptual key-value representation)# as would appear in the Destinations editor of a subaccount Name=S4_ONPREM_ORDERSType=HTTPURL=https://virtual-host-configured-in-cloud-connector:443ProxyType=OnPremiseAuthentication=BasicAuthenticationUser=INTEGRATION_TECH_USERPassword=<stored securely, not in plain config>cloud.connector.location.id=CC_EU1 # In Cloud Foundry, an application or integration flow references# this destination by name (S4_ONPREM_ORDERS) rather than a raw URL,# and the Connectivity service resolves the on-premise route via# the Cloud Connector tunnel identified by cloud.connector.location.id.

Real project scenario

An integration team building a side-by-side extension for S/4HANA Cloud needed to enrich sales order data with a legacy on-premise pricing engine still running on an older ECC system. They chose Kyma for the extension application because it needed to scale dynamically during month-end batch spikes and integrate with an event-driven notification service. To reach the ECC pricing engine, the Basis team installed Cloud Connector inside the corporate network, exposed only the specific pricing RFC-enabled web service path (not the whole ECC application server), and the integration team configured a BTP destination with ProxyType=OnPremise pointing to that Cloud Connector location. When calls started failing intermittently, the team first checked Cloud Connector's administration UI and found the tunnel had been silently disconnected after a network maintenance window, which was resolved by restarting the Cloud Connector service and verifying the connection status turned green again.

Common mistakes

• Choosing Kyma for a simple project without the Kubernetes skills to operate it, leading to slow delivery and operational overhead • Exposing an entire on-premise system through Cloud Connector instead of only the specific required resource paths • Hardcoding backend URLs in application code instead of using BTP destinations, breaking portability across dev/QA/prod • Not monitoring Cloud Connector tunnel health, so connectivity outages go unnoticed until a business process fails • Mixing authentication types inconsistently across destinations, making certificate or credential rotation error-prone

Best practices

• Select Cloud Foundry for straightforward PaaS-style application deployment and Kyma when microservices, custom Kubernetes objects, or event-driven patterns are required • Expose only the minimum necessary backend resource paths in Cloud Connector, never the full system • Always configure connectivity through named BTP destinations rather than embedding URLs in code • Monitor Cloud Connector tunnel status proactively as part of standard landscape health checks • Plan for principal propagation early if end-to-end user identity traceability is a compliance requirement

Interview angle

Candidates are often asked to explain when they would choose Kyma over Cloud Foundry, and how BTP securely connects to on-premise systems without opening inbound firewall ports. A well-rounded answer covers the PaaS-versus-Kubernetes trade-off, the outbound-only tunnel model of Cloud Connector, and the separation of concerns between the Destination service (metadata) and Connectivity service (proxying).