This post attempts to walk-through the demo that was shown at the Ruby Conference. I was not actually at the conference, but I am reconstructing what happened based on materials and information that was tweeted and the presentation materials.
The walk-through above shows a sophisticated PaaS layer (reminding me of the Google AppEngine PaaS) where code is uploaded/pushed and then inspected and compiled. The resulting “App Instance” (also referred to as a “Slug” in Heroku terms) is ready to respond to requests. Can’t service enough requests with just one App Instance? Type “vmc instances fu 5” and instead of a single App Instance, the App Instance clones/copies/ Scales Out to 5 instances.
Need to Scale Down from 5 App Instances to 3 because demand has fallen? “vmc instances fu 3” Scales Down the App Instances from 5 to 3 killing the last 2 App Instances – 3 and 4 (note that instances are numbered 0-4).
Now the requests have fallen to the point where there is only 1 App Instance needed, so the command “vmc instances fu 1” shrinks (Scales Down) the App Instances from 3 to 1. Now we look to see where the fu Application actually is resource utilization wise (This is the point where we see the overlap with the underlying VM) by typing “vmc stats fu”
This allows a Developer on a Public Cloud – in the above case vCloudLabs.com is hosted by Terremark (using vCloud if I had to guess) to deploy their code with little to NO knowledge of the underlying Infrastructure beneath (IaaS). This ultimately mirrors the functionality of what VMware’s Cloud OS will provide to Private Clouds and the Enterprise Development groups inside them. What is demoed is supposed to be the same as the system was designed for VMforce in Salesforce.com ‘s Data Center as well.
Data Gravitas 