Explaining the Key Concepts of SAP BTP, Cloud Foundry Runtime

Applications on Cloud Foundry are your code and any dependencies that are bundled together to perform a specific task. They can be deployed to Cloud Foundry using buildpacks.

To learn how to deploy an application to SAP BTP, Cloud Foundry runtime, refer to the Unit "Managing Deployments in SAP BTP, Cloud Foundry Runtime" of this Learning Journey.

Technically, these applications run in containers, which are isolated environments that provide the necessary resources for the application to run. Containers are managed by the Cloud Foundry runtime and can be scaled up or down based on the application's resource requirements.

Buildpacks are a key component in Cloud Foundry. They're responsible for providing the framework and runtime for applications. When you deploy an application, Cloud Foundry detects the respective buildpack automatically and further uses the buildpack to compile and package your application into an instantiable container image (called droplet). This process is called the application staging.

This information is retrieved from Cloud Foundry Documentation.

There are three types of buildpacks in Cloud Foundry:

• System Buildpacks: These buildpacks are preinstalled in the Cloud Foundry runtime environment and provide support for common programming languages and frameworks.

  They're kept up to date and are supported by SAP. However, they just offer one version. If you use a system buildpack, you automatically consume new versions on the fly, unless you specify a particular version in the URI of the repository when pushing an application to Cloud Foundry. These buildpacks are so-called offline buildpacks, meaning that they don't necessarily require internet access to work.

  See the list of system buildpacks for more information.

• External Buildpacks: These buildpacks offer support for additional languages and frameworks not covered by system buildpacks. See the list of external buildpacks for more information.

  The GitHub organization cloudfoundry-community is not officially affiliated with Cloud Foundry and offers no support, liability, or compliance guarantees. These external buildpacks are sourced from a remote URL and can be any custom buildpack. Unlike system buildpacks, which automatically update to the latest version at unpredictable times, external buildpacks allow for proper version control. This means that you can specify fixed versions, ensuring greater stability and control. Additionally, external buildpacks offer support for those used as system buildpacks, but with the added benefit of managing the versions yourself.

  Caution

  For external buildpacks, it's important to check what it does, who provides it, and if it can be trusted.

  This is an entry point for spyware, malware, and supply chain attacks, and it's negligent to just take any arbitrary buildpack one finds on the internet just because it exists!

• Custom Buildpacks: You can create your own buildpacks tailored to your specific requirements. These buildpacks can be used to package applications that are not supported by the system or already existing external buildpacks. See the buildpack documentation for more information on creating custom buildpacks.

Services are reusable building blocks that provide specific functionalities to your applications, enhancing development efficiency and scalability. These services range from managed services (fully maintained by SAP) to user-provided services (provided and managed by you). They encapsulate complex logic, infrastructure, and data access, allowing you to focus on your core application logic rather than reinventing the wheel.

Services are grouped into two types:

• Business services: These services enable, facilitate, or accelerate the development of business process components or provide industry-specific functionalities or content within a business application. For example: SAP Document Management service.
• Technical services: These services enable, facilitate, or accelerate the development of general or domain-independent content within a business application, independent of the application's business process or task. For example: SAP Application Autoscaler or SAP Authorization and Trust Management Service, and so on.

A service instance is a single instantiation of a service running on SAP BTP, created using a specific service plan, which is a configuration variant of a service. To use a service in your application, you need to create a service instance and bind it to your application.

For an already running application, a restage is required if bindings change, as the binding information is incorporated into the droplet during the staging process. A simple restart will not be sufficient. More information about restage and restart will be discussed in Lesson "Mastering Cloud Foundry Application Lifecycle Events" of the Unit "Optimizing and Managing Applications in SAP BTP, Cloud Foundry Runtime" in this Learning Journey.

Watch the following video to discover the steps for using services in Cloud Foundry.

To view services in the SAP BTP cockpit, navigate to the Cloud Foundry space where you want to use the service, and choose Services → Service Marketplace. The Service Marketplace provides a detailed overview of each service along with information about any service plans, along with the tools needed to create a service instance and bind it to an application.

When you deploy an application to the SAP BTP that requires another service such as the xsuaa service. Make sure that the service instance must be available so that service binding can take place.

You can list all bindings of a respective service, for example, in the SAP BTP cockpit. For this, go to Services → Instances and Subscriptions. From here, select an instance, and you'll see all bindings to deployed applications.

In this lesson, you've discovered the core concepts of SAP BTP, Cloud Foundry runtime, including buildpacks for framework and runtime support, the distinction between applications and services, the use of environment variables, and container management. You should now be able to explain the different types of buildpacks (system, community, and custom), the process of creating and binding service instances, and the roles of service bindings and Service Broker in managing and integrating services within Cloud Foundry.