In the first article in our series on the Cloud Foundry for Developers training course, we explained what Cloud Foundry is and how it’s used. We continue our journey here with a look at some basic terms. Understanding the terminology is the key to not being in a constant state of bewilderment, so here are the most important terms and concepts to know for Cloud Foundry.
Command Line Interface (CLI)
The Cloud Foundry command line interface is a locally installed program that simplifies interaction with a Cloud Foundry instance. The CLI exposes functions (like pushing an app) via the command line, and executes REST calls against a Cloud Foundry target. For more information, see cloudfoundry/cli on GitHub.
Target
A target is a Cloud Foundry installation or endpoint you want to interact with, e.g. by logging in to get information, configuring something, or deploying your application. This endpoint is a standard REST API, and the core API is consistent across all Cloud Foundry distributions. It takes the form of a standard URL, requires login credentials, and your organization and space.
User
That is you! Human users have their own user accounts in a Cloud Foundry instance. Humans users must have organization roles and space roles, with the organization role assigned first. There are also application users, and both human and application users authenticate through the User Account and Authentication (UAA) Server. For more information on users, visit Cloud Foundry Documentation: User Accounts.
Organization
A Cloud Foundry organization logically segregates tenants in a Cloud Foundry instance. The separation is purely logical, and there is no physical segregation. While the use of organizations is required, the method of segregation is arbitrary and left to the end user. Common use cases are for different business units, projects, or even companies (this is common in a hosted CF public cloud). To learn more, visit Cloud Foundry Documentation:Orgs.
Space
An organization is divided into spaces. Applications and service instances are always scoped to a space, and every organization must contain at least one space. Spaces have roles, and these roles apply only to their spaces. Like organizations, the method of separation is left to the end user. You can use spaces for different applications, projects, or lifecycle steps, such as development, testing, and production. To learn more, visit Cloud Foundry Documentation:Spaces.
Quota Plan
Quota plans are logical resource limits for organizations and spaces. A quota plan is a named set of memory, service, and instance usage quotas, for example a set that includes 4GB of memory, 20 services, and 20 routes named “quota1”. Quota plans are not assigned per-user, but rather per organization, so everyone in the organization has the same quota plan. You may create any number of quota plans per account, but assign only one at a time. Spaces may also have quotas, but this is not required. To learn more, visit Cloud Foundry Documentation: Creating and Modifying Quota Plans.
Role
Users are assigned to roles in organizations and spaces. Roles grant granular capabilities to a user. Role names are logical and attempt to convey scope, as well as the capabilities they provide: for example, Admin, Org Manager, Space Developer, and so on.
As a developer, you need the Space Developer role to deploy applications. To learn more, visit Cloud Foundry Documentation:Roles.
In the next blog, we’ll learn about the architecture of Cloud Foundry.
The information in this series is based on the Cloud Foundry for Developers (LFD232) training course from Cloud Foundry and The Linux Foundation. You can download a sample chapter from the course here.
