Embracing The Cloud
public String CloudThoughts{ get; set;}

The VMForce value proposition:

1. Download Eclipse and SpringSource
2. Signup for a Salesforce Development account and define your data model
3. Write your Java app using objects that serialize to Salesforce
4. Drag and drop your app onto a VMWare hosted service to Force.com to deploy
   

The partnership breaks down as:

1. VMWare hosts your app
2. Salesforce hosts your database
   

The 2 are seamlessly integrated so that Java Developers can effectively manage the persistence layer as a black box in the cloud without worrying about setting up an Oracle or MySql database, writing stored procedures, or managing database performance and I/O.

This is all great news for Java Developers. It's yet another storage option on the VMWare cloud (I'm assuming VMWare remains fairly agnostic beyond this relationship and Force.com becomes one of many persistence options to Spring Source developers).

For larger organizations already using Salesforce but developing their custom Java apps, this opens up some new and attractive options.

Existing Salesforce Developers may have wondered if Java would replace Apex and Visualforce, prompting a Salesforce blog post aptly titled "In case you were wondering...". In short, "no". Apex and Visualforce will continue to evolve and be the primary platform for developing Salesforce native apps. I personally will continue to use Apex and Visualforce for all development when the data is stored in Salesforce unless compelling requirements come along to use VMForce (most likely that have particular DNS, bandwidth, or uptime needs).

So why the partnership between VMWare and Salesforce? When Salesforce announced Apex back in 2007 it was met with broad acceptance, but some common criticisms were:

• Why another DSL (Domain Specific Language)?
• Why can't I leverage my existing Java skills to write business apps?
• Salesforce is written in Java. Can I upload my existing Java apps to the cloud?
  

These criticisms were coupled with some looming 800 pound Gorillas in the room (Amazon and VMWare) pushing virtualization as the basis for cloud computing while Salesforce promoted the non-virtualized, multi-tenant path to cloud computing.

They both can't be right. Or can they? CIO's are being bombarded with virtualization as a viable cloud computing solution, so I think Salesforce has wisely taken a step back and taken a position that says "We do declarative, hosted databases better than anyone else. Go ahead and pursue the virtualization path for your apps and leverage our strength in data management as the back end".

Over time, the bet is that VMForce customers will also discover the declarative configuration tools for form-based CRUD (Create/Read/Update/Delete) apps can meet the rapid prototyping and development needs of most any line of business apps.

For object-oriented developers, Salesforce provides a persistence layer that meets or exceeds any ORM (Object Relational Mapping) or NoSQL solution. The impedance mismatch between objects and relational databases is widely known, and VMForce solves this problem very elegantly.

I think other ORM Developer communities, such as Ruby on Rails Developers, will appreciate what is being offered with VMForce, prompting some to correctly draw parallels between VMForce and Engine Yard.

In my experience working with Azure, I cannot emphasize enough how difficult it was to work through the database and storage aspects on even the most simplest application design. Sure, C# is a dream to work with (compared to both Java and Apex) and ASP.NET works well enough for most applications, but Microsoft leaves so many data modeling and storage decisions to the Developer in the name flexibility, which ultimately means sacrificing simplicity, reliability, and in some cases scalability.

Some final thoughts, observations and questions on VMForce:

• Are there any debugging improvements when using VMForce relative to Apex/VF?
  
• 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? (Update: No. Per the comment from David Schach, the app VM is running in the same datacenter as the Force.com DB)
• Licensing: No idea what the pricing will be. Will there be a single biller or will Developers get separate invoices from VMWare and Salesforce for bandwidth/computing and storage?
• It strikes me as quite simple to develop Customer/Partner portals or eCommerce solutions in Java that skirt the limitations of some Salesforce license models when supporting large named-user/low authentication audiences. Will Salesforce limit the types and numbers of native objects that can be serialized through VMForce?
• Will VMForce apps be validated and listed on the AppExchange? If so, will they be considered hybrid or native? What security review processes will be enforced?
• Why only the teaser? Ending a great demo with "and it should be available sometime later this year" just seemed deflating. I think Business Users and Developers respond to this kind of promotion much differently. It would be far better to leave Developers with some early release tools in hand immediately after the announcement and capitalize on the moment. Business Users, however, can be shown Chatter, and other future release features, to satiate their long term interests.
  

Update:Jesper Joergensen has an excellent blog post that answers many of these questions. Thanks Jesper!