VMForce - A Couple Questions Still Remain

For the development side of my job, I work primarily with Force.com using Apex, Visualforce, and the rest of the suite of tools provided by Salesforce.com.  While the tools and languages they provide are great, I still find myself running into issues with missing features, and governor limits imposed to keep the whole system working well.  Needless to say, when I first heard about VMForce I was very excited.  We started speculating about what it will bring to the Force.com world (see this Post), and while most of the general speculations were found to be correct, I feel there are still some questions that must be answered before we can determine how and when to use this new product.

My first unanswered question is one of the things I was most excited about when I first heard about VMForce.  Will it help alleviate governor limits?  I understand governor limits are important to a shared ecosystem.  Letting developers run wild with code would be catastrophic to the entire system, but sometimes the governor limits imposed in Apex are very restrictive.  Things like not being able to query more than 1000 rows with a SOQL statement can make development very difficult.  Will this limit be softened with VMForce?  My guess is, probably not.  While your application will be running on it’s own virtual machine in the cloud, it will still be utilizing Salesforce.com’s databases.  To raise this limit, Salesforce would need to set up some sort of way for you to query against their databases that don’t affect other users.  While I don’t have too much hope that the limits around data access will be raised, I do have some hope that execution limits may be raised.  While Apex runs on the same system as the rest of Salesforce.com, VMForce moves your code out to its own virtual machine.  This should allow for code to run without the threat of hurting other users’ performance on the system.  They say that VMForce will automatically scale to meet your application, so in theory you should be able to have more processing freedom, but it may come at a cost.

This brings me to my next question, how much will it cost?  We know it will not be included with your Salesforce.com licensing, so there will be additional fees incurred for the service.  Salesforce and VMWare say it will scale with your applications, so the logical pricing model would be the more you use, the more you pay.  Hopefully the pricing structure will be comparable to what already exists from vendors like Google and Amazon.  The thought of being able to pick up and move your existing Java applications to the cloud, then tightly couple them to your Saleforce.com organization is very appealing, but if it is cost prohibitive, it may be a hard sell to companies.

While I am still very excited for VMForce, I feel that these two questions really need to be answered before we start to really dig in and come up with the best use cases for this new platform.