BTPbeginner

SAP BTP Overview & Cloud Foundry Environment

The foundational structure of SAP Business Technology Platform - subaccounts, spaces, and Cloud Foundry as one of its runtime environments.

BTP is SAP's cloud platform. Almost every other BTP topic assumes its structure, so start there.

BTP's account hierarchy is like a corporate real estate structure - the global account is the company's master lease with the landlord (SAP), subaccounts are separate floors leased for different departments or projects, and spaces are individual offices on each floor where teams actually set up their equipment (applications) - all governed by how much total space (entitlements) the master lease allows.

Key Concepts

1
The hierarchy.
    global account     the commercial entity, tied to your contract
      subaccount       one per environment or business unit
                       (dev, test, prod) -- the security and
                       quota boundary
        space          Cloud Foundry only: organises apps within
                       a subaccount, usually per team
2
Entitlements flow down, and this is how governance works. The global account holds what you have bought — which services, how much of each. Quota is then distributed to subaccounts.
3
So a project team can provision anything their subaccount was entitled to, without a commercial conversation for every service. And they cannot exceed it, which is the control.
4
Three runtime environments, for three different needs.
    Cloud Foundry     push code, no infrastructure to manage.
                      Node.js, Java, Python and more.
    Kyma              managed Kubernetes, for teams who want
                      container-level control.
    ABAP Environment  cloud ABAP, for RAP development reusing
                      existing ABAP skills.
5
The reason for three is skills and control, not capability. An ABAP team extending S/4HANA uses the ABAP Environment; a team with Kubernetes experience uses Kyma; most application development uses Cloud Foundry.
6
How Cloud Foundry works in practice.
    cf push my-app
7
No Dockerfile and no runtime configuration. A buildpack detects the language, provides the runtime, and the platform handles routing and scaling.
8
Services are bound, not configured. You provision a service instance — a HANA Cloud database, a destination service, event mesh — and bind it to the application:
9
    cf bind-service my-app my-hana
10
The credentials are injected into the application's environment at runtime. Nothing is written into the code or into a configuration file in source control, and the same code runs against a different instance in a different subaccount.
11
Where BTP fits in the wider picture. It is where side-by-side extensions run, where CAP applications are deployed, and where CPI and API Management live.
12
The direction SAP is steering is that anything not strictly needing to run inside S/4HANA itself runs here instead — which keeps the core clean and lets the extension follow its own release cycle.
13
What the interviewer is probing.1. "What are the BTP environments?" Probing: the structure. Stalls: "Just BTP." Moves up: Cloud Foundry, Kyma and ABAP — chosen by the workload, with Cloud Foundry the usual default for CAP and UI5 apps.
14
2. "What is the subaccount for?" Probing: the account model. Stalls: "Grouping." Moves up: the boundary for region, entitlements, trust configuration and the Cloud Connector — effectively the environment boundary.
15
3. "How are services consumed?" Probing: the mechanism. Stalls: "Imported." Moves up: a service instance is created from an entitlement and bound to the application, which injects credentials at runtime.
16
4. "What is the pitfall with entitlements and quotas?" Probing: the practical trap. Stalls: "None." Moves up: a service unavailable in your region or unentitled in that subaccount fails deployment, which is a surprisingly common blocker.