Key Components of Cloud Foundry Runtime
Cloud Foundry runtime provides a robust platform that abstracts many infrastructure complexities, enabling application developers to focus on building and deploying cloud-native applications without getting bogged down by underlying details. This overview covers only the components most relevant to Cloud Foundry application developers, helping clarify how each part contributes to a developer-friendly environment. For a deeper dive into all components, the official Cloud Foundry documentation offers comprehensive details.
The Cloud Controller is the central API endpoint that developers use to manage their applications on Cloud Foundry. It supports essential application lifecycle operations like deploying, scaling, and deleting applications, configuring routes, and binding services. All primary interactions between developers and the platform are handled through the Cloud Controller, making it the core component for managing application states and metadata.
The Routing Layer directs incoming client requests to the appropriate application instances running within Cloud Foundry. It ensures reliable request delivery, load balancing, and high availability by distributing user traffic to the correct services and application instances.
Diego (Container Runtime) manages application execution within isolated containers. It handles scheduling, lifecycle management, and resource allocation of containers, providing a developer-friendly container environment that meets the needs of most business applications while maintaining simplicity.
For secure access, UAA (User Account and Authentication) manages user authentication across Cloud Foundry. It handles user login and token generation, ensuring secure application access while leaving application-specific authorization tasks to the Cloud Controller.
Finally, Loggregator provides real-time logging for deployed applications, aggregating logs and metrics for monitoring and troubleshooting. Developers can access these logs to monitor application performance, diagnose issues, and gain insights into the health and usage of their applications.
Cloud Foundry can be used as a managed service within SAP BTP by enabling the SAP BTP, Cloud Foundry runtime in your subaccount.
A BTP subaccount in a certain Cloud Foundry region will provide you with a Cloud Foundry Organization on the Cloud Foundry installation of that region. Each subaccount thus can only have one Cloud Foundry Organization per region. You can further separate your Cloud Foundry Organization by creating Spaces within your Cloud Foundry Organization.
Organizations
Watch the following video to discover more information about the organization in SAP BTP, Cloud Foundry runtime.
Cloud Foundry organizations have resource quotas, which are given by the SAP BTP subaccount entitlements. See the Cloud Foundry Docs for more.
On the organization level, the only roles that exist are Org Manager, Org Auditor, and Org User. To use a space/be given a space role, an org-level role is required first. See the Cloud Foundry Docs for more details.
Spaces
A space is a container within an organization where you can deploy applications, services, and other resources. It provides a dedicated environment for developing, testing, and running applications without interfering with other spaces. Each space can have its own set of resourcing quotas, such as memory, disk space, and services.
Space quotas limit the resource usage in a more fine-grained method per space. However, if either the space or org quota is exceeded, the resource is exhausted and cannot be requested. See the Cloud Foundry Docs for more.
Additionally, you assign roles to users at the space level to control their access and permissions within that space. This comes in useful when you want to isolate spaces for different projects or teams.