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.
Data Gravitas 
Hmmm… I wonder if VMware is thinking outside the virtual box for some of these services. The temptation so far has been to make “services” be limited to VM deployed instances. Your middle service tier appears to be web services. Do you know if VMware also sees SQL, Tables, Cache, etc as deployable services?
Hey Rob-
Yes we see these as ‘services’ in our system. We will have a services SDK so anyone can add services to the cloud and advertise them into the system. Therefor allowing other customers. or just your own account to access and create instances of these services and bind them to specific applications.
I find it very interesting that this is being marketed as an “Open” platform. While the API is open.. its useless in avoiding vendor lock-in unless a bunch of other cloud vendors adopt/support the Force API. Are you willing to bet months of developer resources on that? And if you do take that gamble, how long will you be locked in until some finally does adopt the Force API? And will they be who you want to work with? The proper solution here is to use a vendor which provides a complete ECA Stack (http://mor.ph/blogs/what-so-important-about-enterprise-cloud-architecture), is fully functional to the end user without knowing an API, supports Java, PHP, Ruby/Rails out of the box, is fully multi-tenant and can run on a EC2 and/or your own datacenter. Morph Labs’ ‘mCloud’ offerings are the only solution I have seen that does this (http://www.mor.ph/). Force has some great offerings.. but an open, non locked in stack?.. They just aren’t there yet.
If your data already lives in Salesforce then you are already vested and the fastest path to bringing new applications on line would be to leverage VMforce and Force.com. This is true with all Cloud solutions (Public at least). I don’t understand the “locked-in” point past this. Every platform has a level of investment that is made that causes customers to choose it, this is the nature of one solution versus another.
Who are you referring to as the end-user?
BTW, EC2 has a proprietary API (people use it, but Amazon has not publicly endorsed their API as open for anyone to use as they will to my knowledge)
As for Open Pass / VMforce being open, it is (the client code even in the Alpha/Beta state, can be changed, viewed, etc.) In fact for my posts up to this point, I have leveraged looking at the Open PaaS code and VMware has provided rapid feedback on my posts. I don’t see how they could be more open!
Hi, I agree that if your data already lives in SalesForce then this is a great solution. It is much more Enterprise class in it’s structure (HA, Clustered, etc.) then I have seen is most other cloud offerings. So In that respect SaleForce has done a great thing with this. My point is that if you do not have a Cloud solution and need one, I don’t believe Salesforce is the way to go. It takes a fair amount of integration effort to move your application to Force.com. Using a truly open standards and FULL stack you don’t have to change your code to deploy and have an Enterprise level infrastructure behind it. For example in mCloud the developer or sysadmin can deploy the application directly from their desktop to a fully clustered, HA environment, without changing their code. This is something I feel is a necessity if you are choosing a new cloud stack.
We were previously talking about VMforce and Open PaaS, now the discussion is changing to focus. mCloud looks like a great IaaS solution by what you are saying, however if I was looking at an Enterprise at Cloud, I wouldn’t be looking to run my Application in a Public/Hosted IaaS. I would look to run this type of solution internally, if I was looking to run my solution externally I would re-architect it accordingly to take advantages of the cost benefits and eliminate the costs/overhead associated with clustering, HA, and the like. Open PaaS on top of VMware is likely to fill this need for many enterprises, as they have already deployed/invested in it.