Tuesday, November 16, 2010

More on VMforce - Part Deux

I blogged about VMforce a couple of times back in April.  In August, VMware/SpringSource and SalesForce.com provided more details about this service in a couple of webinars to introduce Spring framework to Force.com developers, and Force.com & VMforce to Java developers:

VMForce–Cloud Computing for Java Developers

Basically, VMforce enables developers deploy JEE webapps on Force.com, and access Force.com database to persist data using standard JEE interfaces (JPA):


SpringSource offers the tooling (STS) to easily build and deploy Spring-based applications to VMforce. Force.com implements a JPA adapter to provide secure, multi-tenant access to Force.com database.

On the development/tooling side, it doesn’t seem the Force.com Eclipse Plug-in can be installed on STS (yet).  Once they work this out, both sets of developers can install one Eclipse to implement either JEE/Spring apps or Apex. 

I think the significance of VMforce is beyond merely extending Force.com with Java EE support or providing extensibility for Apex applications.  VMforce is significant, because it will support the most common approach to Cloud migration by customers.   Customers need a reliable service from a reputable, enterprise-ready service provider to move their existing applications to the cloud as is without much re-factoring.  This is going to be the trend for the next few years.  VMforce is a key strategy to meet that need. 

And, of course with Spring framework programming model (abstraction, dependency injection), there is a good story for platform lock-in and change management.

What is not completely clear so far is how VMforce will meet monitoring and on-premise integration requirements for customers.


Side note:

As I am writing this, I can understand how Google and SalesForce have partnered with SpringSource today to enable implementation of Cloud apps using the framework (i.e. skills).  However, this framework is based on “legacy Java EE” development and deployment.  Java EE, as it exists today, does not cover Cloud distributed programming model and patterns, and I don’t know if it could be easily extended to support them.   The problem here is that customers may have to invest in migration in the future.

However, there is no practical alternative available today.  Until there is standardization around Cloud development, deployment, and interoperability, Spring-based development seems to be a logical approach.



No comments: