As I discussed in my post at the end of April, the Cloud Controller is undergoing major surgery and this work is being done in the cloud_controller_ng repo. If you are following the review stream for the cloud_controller_ng project, its time to take note of the new Organization and AppSpace objects. These objects are the foundation of several new features we are rolling out this year:
- operational collaboration
- advanced quota management and control
- custom domains and assorted application features
This post will focus on the objects themselves and will discuss operational collaboration to demonstrate their significance. Other features will be discussed in subsequent posts.
In order to understand the new objects, its best to briefly review the current model and to understand some of the limitations with that scheme. The diagram below is a high level view of the current cloud controller model.
In this scheme, each user account directly contains both named applications and named service instances. The names are scoped to the user account object, and only that account can manipulate the applications and services. The simplicity of this model exposes an operational issue that can occur when more than a single person is responsible for ongoing maintenance of an application.
The issue is that when your production application is created under a given account, ONLY that account can manipulate the app (update the code, scale it out, increase its memory size, etc.). For a single developer operation, this works fine. However, once you have more than one person responsible for an app (e.g., your small 3-man startup), this approach is problematic. To compensate for this, people either use a shared account, share passwords, or have to invoke admin privileges which allow an admin to manipulate the objects in another user’s account. These solutions all work, but all are poor solutions that expose their own set of problems (inability to generate a precise audit log of who did what, too many folks with admin privileges, etc.)
The new model is designed to address the aforementioned deficiencies in a scalable and sustainable way, and at the same time, provide us with the foundation needed in order to deliver additional advanced features.
The diagram below is a high level view of the new cloud controller model.
Under the new model, applications and services are now scoped to a new object called the AppSpace. Multiple users can have access to an AppSpace, and each user has a set of permissions that determine what operations she can perform against the applications and services within the space. Instead of shared accounts, sharing passwords, or invoking admin rights, you can simply create an AppSpace for your production facing applications and then allow a select group of developers to manipulate the apps and services within that space.
We have taken things a step further than this with the introduction of the Organization object. This object can contain a number of AppSpaces as well as a membership list of users, etc. If you are familiar with the GitHub account model, if you squint real hard you can see that from a scoping and permissions standpoint, a GitHub Organization and a Cloud Foundry Organization are very similar, and a GitHub repo and a Cloud Foundry AppSpace are similar.
I’ll save the details on advanced quota management and features for another post, but if you read the code and review stream you can see how we are using these new objects as a foundation for quota management, custom domains, and many more advanced features.
-markl
Mark Lucovsky, VP of Engineering – Cloud Foundry
About the Author
