I have been using GAE and find that it has some quirks as a web platform. It is basically a quirky JVM in the clouds.
VMForce should prove to be a much less quirky JVM. The Spring stack (Tomcat/tcServer, Spring, Groovy & Grails or Java & Roo) is mainstream JVM. I tried to run Grails, and Gaelyk, on GAE, but gave up when I realized how long it took to load a dynamic language after users hit the web site.
It seems pretty likely (but I have not verified) that VMforce will be optimized for Grails development. This is an exciting prospect.
The recent addition of RabbitMQ/AMQP looks like VMforce will be able to go toe-to-toe with Google's pubsubhubbub. Very interesting.
This guest post comes courtesy of Tony Baer’s OnStrategies blog. Tony is a senior analyst at Ovum.
By Tony Baer
Go to any vendor conference and it gets hard to avoid what has become “The Obligatory Cloud 
Presentation” or “Slide.” It’s beyond this discussion to discuss hype vs. reality, but potential benefits like the elasticity of the cloud have made the idea too difficult to dismiss, even if most large enterprises remain wary of trusting the brunt of their mission systems to some external host, SAS 70 certification or otherwise.
So it’s not surprising that cloud has become a strategic objective for VMware and SpringSource — both before after the acquisition that brought them together. VMware was busy forming its vCloud strategy to stay a step ahead of rivals that seek to make VMware’s core virtualization hypervisor business commodity, while SpringSource acquired CloudFoundry to take its expanding Java stack to the cloud (even as such options were coming available for .NET and emerging web languages and frameworks like Ruby on Rails).
Following last summer’s VMware SpringSource acquisition, the obvious path would have placed SpringSource as the application development stack that would elevate vCloud from raw infrastructure as a service (IaaS) to a full development platform. That remains the goal, but it’s hardly the shortest path to VMware’s strategic goals.
At this point, VMware still is getting its arms around the assets that are now under its umbrella with SpringSource. As we speculated last summer, we should see some of the features of the Spring framework itself, such as dependency injection (which abstracts dependencies so developers don’t have to worry about writing all the necessary configuration files), applied to managing virtualization. But that’s for another time, another day.
VMware’s more pressing need is to make vSphere the de facto standard for managing virtualization and making vCloud, the de facto standard for cloud virtualization. (Actually, if you think about it, it is virtualization squared: OS instances virtualized from hardware, and hardware virtualized form infrastructure.)
In turn, Salesforce.com wants to become the de facto cloud alternative to Google, Microsoft, IBM, and when they get serious, Oracle and SAP. The dilemma is that Salesforce up until now has built its own walled garden. That was fine when you were confining this to CRM and third-party AppExchange providers who piggybacked on Salesforce’s own multi-tenanted infrastructure using its own proprietary Force.com environment with its “Java-like” Apex stored procedures language.
But at the end of the day, Apex is not going to evolve into anything more than a Salesforce.com niche development platform, and Force.com is not about to challenge Microsoft .NET, or Java for that matter.
The challenge is that Salesforce, having made the modern incarnation of remote hosted computing palatable to the enterprise mainstream, now finds itself in a larger fishbowl outgunned in sheer scale by Amazon and Google, and outside the enterprise, the on-premises Java mainstream. Salesforce Chairman and CEO Marc Benioff conceded as much at the VMforce launch this week, characterizing Java as “the No. 1 developer language in the enterprise.”
So VMforce is the marriage of two suitors that each needed their own leapfrogs: VMware transitions into a ready-made cloud-based Java stack with existing brand recognition, and Salesforce.com steps up to the wider Java enterprise mainstream opportunity.
Apps written using the Spring Java stack will gain access to Force.com’s community and services such as search, identity and security, workflow, reporting and analytics, web services integration API, and mobile deployment. But it also means dilution of some features that make Force.com platform what it is; the biggest departure is away from the Apex language stored procedures architecture that runs directly inside the Salesforce.com relational database.
Salesforce pragmatically trades scalability of a unitary architecture for scalability through a virtualized one.
It really means that Salesforce morphs into a different creature, and now must decide whom it means to compete with because — it’s not just Oracle business applications anymore.
Our bets are splitting the difference with Amazon, as other SaaS providers like IBM that don’t want to get weighed down by sunk costs have already done. If Salesforce wants to become the enterprise Java platform-as-a-Service (PaaS) leader, it will have to ramp up capacity, and matching Amazon or Google in a capital investment race is a nearly hopeless proposition.
This guest post comes courtesy of Tony Baer’s OnStrategies blog. Tony is a senior analyst at Ovum.
