After having gone through the materials available (both the easy to find and the difficult to find) I have created what should be an accurate view of what the environments inside a VMware Open PaaS and VMforce world should look like. In this post is a series of diagrams that I have created based on what I have concluded is the way the current system works.
In the diagram above, starting at the top:
- Organization Context – This is likely a sub-Cloud of the overall Cloud, but I haven’t been able to clarify this in the code yet. It provides authentication and determines which services are available to be used and shared amongst User Accounts (aka Service Domains)
- User Account – This is done by registering an e-mail address and a password, each account is allocated a quota which is controlled by an administrator.
- URL – This is how external Applications, Users, APIs, etc. access the Application
- Mapping – Connects the URL to the Application (Allowing Applications to be Switched beneath the URL)
- Application – Also know as a “Droplet”, is made up of App Instances and connect to Service Instances
- Service Instances – Are useable/consumable/invoked instances of services from the Service Catalog
- Service Catalog – This is the listing of all available services that can currently be invoked for use by an Application
The above diagram shows a slightly more filled out Service Catalog. These are the services that were provided as examples by the VMware presentations and documentation that I have seen so far. The diagram also shows an even larger number of applications running, although each only has a single App Instances associated with it.
In this diagram (above), there are two URLs each providing access to an Application. The first application on the left has a single Application Instance and that App Instance is bound (see Binding Labels) to a MySQL Instance (Service Instance) and a RabbitMQ Instance (Service Instance). The two Service Instances are created from the Service Catalog’s MySQL and RabbitMQ entries.
The second Application has three App Instances inside of it, all of which are bound to the SAME RabbitMQ Instance that the first Application is (this means that the two Applications can share information through the RabbitMQ Instance). The MySQL Instance is a separate MySQL Instance from the first Application MySQL Instance, although both are based/invoked from the MySQL Service in the Service Catalog. The Redis, Memcache, and MongoDB instances are all bound to each of the App Instances in the second application and are used by all three instances.
The final Diagram is from information I came across while digging through the VMC Ruby code. The code has fields in it for “Service Tiers”, which based on some poking around on Salesforce’s website, I came up with the above possibilities. I don’t know if this is 100% accurate, but based on the information I think it provides a pretty reasonable approach to exposing provider services to Developers looking to write code on a Cloud platform such as VMforce.
There are several more interesting things that I have come across since I began going through the code. I will be blogging about them soon.