It's been a few weeks since the VMforce announcement and it's been great to follow the many comments and posts both before and after we announced what VMforce is about.

Mike Leach posted this one with a couple of questions shortly after the event and it was followed up by this one by Joel Dietz with some additional thoughts and questions. I'll try to answer some of those questions here:

"Are there any debugging improvements when using VMForce relative to Apex/VF?"

One of the design goals with VMforce is to get out of the way of the developer and let you write code the way you normally do (to the largest extent possible). In many cases you'll be able to develop most of your application locally and use your local debugging tool. When you deploy to VMforce, it will be a little harder to allow you to attach a debugger, but we're looking at ways to enable "cloud" debugging as well. Our current thinking is that local debugging will go a long way to address debugging needs.

As you develop locally, you can, in theory also use a local database, but we expect most developers use a developer org/sandbox during local development.

"The connection between VMWare and Salesforce is presumably via webservices and not natively hosted in the same datacenter. Does this imply some performance and latency tradeoffs when using VMForce?"

VMforce is a single service offered jointly by VMware and Salesforce.com and the Java applications will be hosted in the same data center as the database. However, VMforce applications should definitely be optimized for minimal database roundtrips since they are loosely coupled and physically separated from the database. This is no different from many other multi-tier application architectures in use today.

"Licencing: Single biller?"

VMforce is a single service and customers will not be billed separately by VMware and Salesforce for its use.

"Will Salesforce limit the types and numbers of native objects that can be serialized through VMForce?"

There are already limits on this today and we will evaluate and update those limits if necessary to accommodate VMforce use cases.

"Why only the teaser?"

We think it was important to say what we're going to do, but we still have some work to get there. Apologize for not being able to give you something to play with right now, but we're working on it.

"Pricing Model"

Stay tuned for more info. But I do want to make one comment to Joel Dietz' point:

"…the obvious answer for developers working off of PaaS is resource based pricing, which is clear and transparent in the case of Google and Amazon, but a bit murkier in the case of Salesforce."

Amazon is not PaaS, so it's a bad choice for pricing model comparison. Google doesn't offer close to as rich a feature set (if you think about everything you can do on Force.com, not just VMforce) so they are not a good comparison either.