with inputs from various Pivotal Experts (Joe Fitzgerald, Stuart Radnidge)...
Let’s firstly look at orgs and spaces. An organization, or an org, is a set of users grouped together for management purposes, and all members of an org share the same resource quota plan, services availability, and their custom domain. In an nutshell, organizations allow you to create a multi-tenant environment within your pivotal cloud foundry deployment.
Organizations can be defined any way that you like. Typically, they’re defined around things like line of businesses, or particular projects, or a specific division, or an initiative. There’s no sort of right way to do it. There’s the way that suits your organization, is really the way to do it. You don’t want to overdo the orgs, but orgs give you a level of abstraction that enables you to define who can do what in a particular environment.
Associated with these orgs are quota plans, and a quota will apply to all the activities within their particular organization, and in particular they provide limits and tracking around memory and disk use. Memory that is used by application instances; the services the consume, so how many services you can allocate to applications within that environment; and the number of routes, or ‘roots’, depending on where you come from, to applications that are allowed to be configured. These are custom or multiple domains that can be configured so you can control limits on all of those.
Within each organization, you can have multiple spaces. Each org will have at least one space, you have to have one, and every application and service is scoped to a space. Spaces are a very important additional level of abstraction for organizing applications and services. A space gives you access to a shared location for application development, deployment, and maintenance, and users will have specific space-related roles.
What do we normally organize our spaces into? The kind of canonical version is really having a development space, a test space, a staging space, and a production space. That’s one example. It’s not the only example, but it shows you how you can move an application through different spaces based upon your development pipeline, and have different roles and responsibilities allocated to that space, and different things happening in those particular spaces.
In non-prod deployments, it makes sense to allow developers to experiment with Cloud Foundry in their own org. Heritage Pivotal Elastic Zones (PEZ), Pivotal’s Cloud Foundry offering for all Pivots, implements this model. In this scenario, a developer is given their own organization, and the developer is made the OrgManager of that org. A limited quota is assigned to this org, which that developer can view but can’t change. As a result, the developer can create as many spaces as they want to within this org, can bind service instances, etc, but can only consume a limited amount of resources with the application instances that they push to Cloud Foundry. This enables them to explore the platform, test various scenarios, etc without cluttering up other orgs and spaces.
So our recommendation in a nutshell is – Create an org for a business unit or line of business and then one space per logical environment like dev, test and performance. Start simple and then customize as dictated by requirements. Org= sensible business unit – a space per environment.
In non-prod deployments, it makes sense to allow developers to experiment with Cloud Foundry in their own org. Heritage Pivotal Elastic Zones (PEZ), Pivotal’s Cloud Foundry offering for all Pivots, implements this model. In this scenario, a developer is given their own organization, and the developer is made the OrgManager of that org. A limited quota is assigned to this org, which that developer can view but can’t change. As a result, the developer can create as many spaces as they want to within this org, can bind service instances, etc, but can only consume a limited amount of resources with the application instances that they push to Cloud Foundry. This enables them to explore the platform, test various scenarios, etc without cluttering up other orgs and spaces.
So our recommendation in a nutshell is – Create an org for a business unit or line of business and then one space per logical environment like dev, test and performance. Start simple and then customize as dictated by requirements. Org= sensible business unit – a space per environment.
Alternate Approach: All the people with access to an org get read access to everything in that org, which means service credentials for every app in the org, if you map an org to a business unit, and have multiple apps. To prevent this kind of credential and access leakage across apps in an org, another way to structure apps is one org per app and a space per environment. If the inventory and chargeback model is around apps then it is easier to map orgs to apps for that too.
References
- Insight into setting quotas
- Monitoring Application Instance Usage in PCF
- http://apidocs.cloudfoundry.org/230/organization_quota_definitions/creating_a_organization_quota_definition.html
-http://apidocs.cloudfoundry.org/230/space_quota_definitions/creating_a_space_quota_definition.html
- https://docs.cloudfoundry.org/concepts/roles.html
- http://www.paasmag.com/2016/01/13/quotas-vs-trust/
- Monitoring Application Instance Usage in PCF
- http://apidocs.cloudfoundry.org/230/organization_quota_definitions/creating_a_organization_quota_definition.html
-http://apidocs.cloudfoundry.org/230/space_quota_definitions/creating_a_space_quota_definition.html
- https://docs.cloudfoundry.org/concepts/roles.html
- http://www.paasmag.com/2016/01/13/quotas-vs-trust/
