William Vambenepe's blog

Three weeks ago, VMWare and Salesforce.com launched VMForce, a Salesforce-hosted PaaS solution based on VMWare runtime technology and force.com application services. In my analysis of the announcement, I wrote:

VMWare wants us to know they are under the covers because of course they have much larger aspirations than to be a provider to SalesForce. They want to use this as a proof point to sell their SpringSource+VMWare stack in other settings, such as private clouds and other public cloud providers (modulo whatever exclusivity period may be in their contract with SalesForce)

Well, looks like there wasn’t much of an exclusivity period after all as today VMWare is going an another date, with Google App Engine (GAE) this time. But a comparison of the two partnerships reveals that there is a lot more in the VMForce announcement than in today’s collaboration.

The difference in features

Before VMForce, we could not deploy Java applications on force.com. After VMForce we can (with the restriction that they have to be Spring-based). That’s a big difference. On the GAE side, the announcement today that we can now more easily run Spring Roo applications on GAE is nothing drastic. We could do it before, it was just harder. There was an ongoing effort to simplify it and there was no secret about this. Looks like it has delivered some improvements as part of the 1.1.0.M1 release. This only becomes major news via the magic of being announced as Google I/O rather than as an email on a developer mailing list.

Now, I don’t want to belittle the benefit of making things simpler. Simplicity is a feature. Especially for Roo where it is key to the value proposition. This looks very nice (and will probably push me over the edge to actually give Roo a spin now that I have an easy way to host whatever toy app I produce). It just doesn’t represent a major technology announcement.

The difference in collaboration

Salesforce is using VMWare infrastructure to run VMForce.com. They present a unified customer support service across the companies. They also presumably have some kind of revenue-sharing agreement. That makes for a close integration as far as business partnership go. No such thing that I can see on the Google side. No VMWare hypervisor is getting inside the Google infrastructure. No share of revenues from Google App Engine for Business goes to VMWare (any SpringSource infrastructure used is brought by the customer, not provided by Google, unlike with VMForce). And while Rod Johnson asserts that “today’s announcement  makes Spring the preferred programming model for Google App Engine” (a sentence repeated on the vCloud blog), I don’t see any corresponding declaration on the Google side that would echo the implicit deprioritization of Python and non-Spring Java support. Though I am sure they had nice things to say on stage at Google I/O. From Google’s perspective this sounds more like “we’re happy that they’ve made their tools work well with OUR infrastructure” than an architectural inflection. I think Google has too much pride in their infrastructure to see VMWare/SpringSource as an infrastructure provider rather than just a tool/library. But maybe I’m just jealous… And tools are important anyway.

What we’re not seeing

These VMWare+Salesforce and VMWare+Google announcements are also interesting for what is NOT there. Isn’t it interesting that the companies that VMWare enables with a PaaS platform are those which… already have a PaaS platform? What we haven’t seen is VMWare enabling a mid-tier telco to become a PaaS provider. Someone who has power, servers and wires and wants to become a Cloud provider. VMWare is just starting to sell them an IaaS platform (vCloud) and cannot provide them with a turnkey PaaS platform yet by lack of application services (IDM, storage…) and of a comprehensive (i.e. not just virtualization) management platform. Make a list of what application services you think a PaaS platform requires and you probably have a good idea of the VMWare shopping list. But with Salesforce and Google this is not a problem, as they already have these services and all they need from VMWare is an application runtime (or just a runtime interface for Google) and some development tools.

The application services are also where the real PaaS portability issues appear. Which is also probably why Salesforce.com and Google are not too worried about being commoditized as interchangeable Spring runtime infrastructures. They know that the differentiation is with the application services. Their respective values in this domain are their business focus (processes, analytics, SaaS integration) for Salesforce and their scalability and low cost for Google (and more and more also the SaaS part). Not to mention Amazon who is not resting on its IaaS laurels and also keeps innovating in Cloud application services (e.g. RRS just yesterday). On their side, the value proposition seems to be centered on practicality and scale.

This is good news overall. As Steve Herrod writes, SpringSource has indeed been very busy and displays an impressive amount of energy in figuring this PaaS thing out. We’re still in the very early days of the battle of the Cloud Frameworks and at this point the armies are establishing beachheads and not yet running into one another. There is plenty of space for experimentation. 2010 is the year of PaaS.

Related posts:

1. PaaS portability challenges and the VMforce example
2. Analyzing the VMforce announcement
3. Thoughts on VMWare, SpringSource and PaaS
4. Spring flowers
5. Google App Engine: less is more
6. Google App Engine is teasing me

Follow @vambenepe on Twitter.

This entry was posted on Wednesday, May 19th, 2010 at 5:10 pm and is filed under Everything. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.