The "all in" Kitchen Sink ...or Not !

Anand Rao · May 7, 2018

The Art of Org and Space Management in PCF.



Image result for kitchen sink full
We have all seen this in our kitchen 


A Quick introduction: Pivotal Cloud Foundry provides a collaboration model with isolated workspaces for Application deployment and management. The virtual allocation of workspaces follows a hierarchy of Organizations and spaces inside them.

The Org ( Organization)  is  controlled by a Role Based Access Control ( RBAC)  which is used to controls Quota management for each org by the operators as well as controlled Access to Users within the Org to perform specific actions.

A Space is one of many isolated workspaces(space), created within the Orgs by the Org users (collaborators) to deploy and manage applications. By default the applications deployed in the spaces are isolated and so are the the services that are created within the spaces. This means, by default all services created inside a space are allowed to be bound to apps inside the same space. This is true even to instances of Spring Cloud Services, unless  you have adopted Spring Cloud Services 1.2 . SCS 1.2 comes with Multi-Site Service Discovery which can be applied across different Orgs on the same PFC foundation as well as across Foundations.

Now , Lets look at this in a different perspective. Folks have followed the rule where, a particular team uses a single space for all its applications. This is where the kitchen sink analogy comes into picture. Having potentially 100s of apps in a single space becomes a little unmanageable. Even though this does not have a direct impact on app placement across AZs and the use of affinity rules,  the clutter of of too many criss-crossing apps that call one another all deployed within a single space is not a pretty picture.

This is when I want to introduce the concept of Apps in a Box. Think about a set of microservices (apps) that form a logical application by interacting with one another and with the services that they potentially share. This, of course will need them to be able to discover each other's instances.

Based on my experience and talking to multiple folks who have been there,  I think ,  the best logical organization of Orgs and Spaces as follows:

  • Real Organizations of teams that work on a platform ( group of common Applications) should be grouped into Orgs. 
    • The Collaborators in those Orgs should have access to see( read)  all the Spaces to help with cross team collaboration.  
  • Spaces would make perfect sense  for a Single App in a Box ( should we say App in a Space ? )
    • On the development foundations ( I have seen customers use  Orgs for Environment Separation like Dev vs QA vs Stage),  you would be giving the Space Developer and Manager access to the developers who are actively working on the Apps that form a logical group. 
    • In the spirit of being totally cloud native,  we should always insist on using a discovery process to find microservices that are needed as upstream services. 
    • Non-Development ( see how I don't talk about prod and non-prod here ) , should always get the app deployments via pipelines triggered by Code commits or  other triggers and should always  use a cloud foundry user ID  created specifically for use by the pipelines. 
    • The Developers should not be given access to the Orgs and Spaces running non Development workloads. 
    • Tests  should be automated and executed via pipelines. 
    • Multiple Data Flavors could be ingested for running different sets of focussed tests.  
    • With Autoscaling in place ,  we should execute our automated performance tests as part of the same pipeline as well. 
With the above way of Organization ,  one would get a clear logical grouping.  This would also mean  that the same collaborators could be part of the development lifecycle of multiple Apps in a Box and thus have a role on multiple spaces. But from a Security and control perspective ,  the apps are built and deployed in the application perspective rather than the Team that builds them. 

Another major advantage of using the pipelines approach is that it automates all kinds of tests be it functional and unit tests  or the performance tests  that trigger huge but short term application scaling allows you to convert all the infra used  for the pipeline execution as ephemeral.  Once the tests are completed,  you can and should do a
 cf delete
on all the apps that form that box.  This approach has helped reduce substantial infra needs at customers and helped promote hands off pipelines and eliminate the Works on my computer syndrome. You leave behind a clean space and a well managed Org on Cloud Foundry.  The Operators will be pleased that their clean up scripts will not find forgotten ,  left behind apps and services. 

This should leave your kitchen sink looking like this :) 

Related image
Who would not want this ??




Twitter, Facebook