Planning Orgs and Spaces

Overview
How Cloud Foundry Layers Relate to Your Company
Mapping Considerations

This topic describes considerations for effectively planning foundations, orgs, and spaces. You can plan your orgs and spaces to make the best use of the authorization features in Cloud Foundry Application Runtime.

Overview

An installation of Cloud Foundry is referred to as a foundation. Each foundation has orgs and spaces. For more information, see Orgs, Spaces, Roles, and Permissions.

The Cloud Foundry roles described in Orgs, Spaces, Roles, and Permissions use the principle of least privilege. Each role exists for a purpose and features in Cloud Foundry enable these purposes.

Consider these roles when planning your foundations, orgs, and spaces. This allows for full use of the features and assumptions of Cloud Foundry.

How Cloud Foundry Layers Relate to Your Company

The following sections describe what Cloud Foundry layers are and how they relate to your company structure.

Overview of Cloud Foundry Layers

For an overview of each of the structural Cloud Foundry layers, see the following table:

Cloud Foundry Layer	Challenge to Maintain	Contains	Description	Roles
Foundations	Hardest	Orgs	For shared components: domains, service tiles, and the physical infrastructure	Admin, Admin Read-Only, Global Auditor
Orgs	Average	Spaces	A group of users who share a resource quota plan, apps, services availability, and custom domains	Org Manager, Org Auditor, Org Billing Manager
Spaces	Easiest	Apps	A shared location for app development, deployment, and maintenance	Space Manager, Space Developer, Space Auditor

Foundations

Foundations roughly map to a company and environments. See the following diagram for an illustration:

The diagram shows a box on the left labeled 'Your Company' and a box on the right labeled 'Cloud Foundry'. In the 'Your Company' box, there are two smaller boxes labeled 'Company' and 'Environment', which are linked to a section in the 'PCF Organizational Model' labeled 'Foundation'.

Orgs

Orgs most often map to a business unit in a particular foundation. To understand how you can map your company structure to a Cloud Foundry org, see the diagram below:

orgs can encompass Business Units, environments, teams, or products

Spaces

Spaces can encompass teams, products and specific deployables. To understand how you can map your company structure to a Cloud Foundry space, see the diagram below:

Spaces can encompass Teams, Products and specific deployables

Mapping Considerations

The sections below describe considerations you can make when mapping foundations, orgs, and spaces.

Environment Planning

To plan your environments effectively, you must decide at what Cloud Foundry layer they belong.

Broad environments, such as production environments, are commonly mapped to a foundation. More specific environments are mapped to an org or space.

Because of the large human cost to maintaining a foundation, you may see foundations mapped to production and staging environments separately.

For examples of environments and how they map to Cloud Foundry layers, see the following table:

Cloud Foundry Layer	Examples of Environments
Foundations	Production, Non-production, Sandbox
Orgs and Spaces	Development, UAT, QA

Questions to Consider About Each Cloud Foundry Layer

For guiding questions to help you make decisions about planning your Cloud Foundry structure, see the following table:

Cloud Foundry Layer	Questions to Consider
Foundation	How many foundations can your platform team create, update, and monitor? How much isolation does your organization require? Do you need foundations local to a particular cloud or IaaS environment?
Org	How do you plan for capacity needs and changes? What groups need to self-organize together? How do you measure cost and perform billing and chargeback?
Space	Are teams building single apps or constellations of microservices? Are teams building a portfolio of apps or standalone apps? When should a new space be created or destroyed? What developer processes require the sandboxed isolation? Do all apps need public routes? What apps need to share the same service instance?

Impact of Mapping Larger and Smaller Subsets

Subsets are the company divisions you decide to map to Cloud Foundry. When creating your subsets, consider that the lower the Cloud Foundry layer, the more specific you want to map your subsets. Conversely, the higher the Cloud Foundry layer, the broader you want to make your subsets.

For more information about mapping larger subsets for each Cloud Foundry layer, see the following table:

Cloud Foundry Layer	The impact of mapping larger subsets of your company
Foundations	Less maintenance Less isolation Better use of shared platform components
Orgs	Less quota micromanagement Ability to delegate user onboarding More likely there are people with divergent needs BU must be platform trained and manage potentially many spaces
Spaces	More likelihood of accidental changes to someone else’s app or service Easier integration between apps More apps can use non-public routes

For more information about mapping smaller subsets for each Cloud Foundry layer, see the following table:

Cloud Foundry Layer	The impact of mapping smaller subsets of your company
Foundations	More maintenance, which could be offset with platform automation Higher likelihood of foundations being different More isolation
Orgs	More quota management from platform team More freedom to create spaces as needed
Spaces	More app isolation Security with more specific ASGs More reliant on external services or service instance sharing

View the source for this page in GitHub