Salesforce and Google have teamed up with VMware to promote cloud portability but like beauty that portability is only skin deep.

VMware has been moving of late to form strategic partnerships that enable greater portability of applications across cloud computing providers. The latest is an announcement that Google and VMware have joined forces to allow Java application “portability” with Google’s App Engine. 

It is important to note that the portability resulting from this latest partnership and VMware’s previous strategic alliance formed with Salesforce.com will be the ability to deploy Java-based applications within Google and Force.com’s “cloud” environments. It is not about mobility, but portability. The former implies the ability to migrate from one environment to another without modification while the latter allows for cross-platform (or in this case, cross-cloud) deployment. Mobility should require no recompilation, no retargeting of the application itself while portability may, in fact, require both. The announcements surrounding these partnerships is about PaaS portability and, even more limiting, targeting Java-based applications. In and of itself that’s a good thing as both afford developers a choice. But it is not mobility in the sense that Intercloud as a concept defines mobility and portability, and the choice afforded developers is only skin deep.

The mobility of an application deployed atop a PaaS is exceedingly limited for two reasons. First, you are necessarily targeting a specific platform for applications: .NET, Java, PHP, Python, Ruby. If that was the only issue then alliances such as those between VMware and Google and Salesforce.com might be of broader appeal. But the second limiting factor with PaaS is the use of proprietary platform services such as those offered for data, queuing and e-mail.

Both announcements make mention of the ability to “tap into” or “leverage” platform services, which is ironic when mentioned within the context of a partnership that is intended to help customers avoid cloud “lock-in”  because there is almost no way to avoid cloud “lock-in” when an organization commits to integrating with the proprietary services of a PaaS (Platform as a Service) solution. 

None.

Such platform services are proprietary. Closed. Non-portable. They are services that, once your application is dependant upon, you are “locked in.” If you use Force.com’s “Chatter collaboration” your application is now dependent upon that service and is locked into that platform. If you tie yourself to any of Google App Engine’s proprietary services (data store, e-mail services), you are locked into that platform. You can’t move the application else unless you extract the integration with those services and replace it with something else. The same is true for Amazon EC2 and its services (SQS, SNS, etc…). Integration with those services necessarily makes your application dependent on the service and thus that particular “cloud”. It locks you in.

This is the same problem suffered by IaaS (Infrastructure as a Service) providers today and is the same problem organizations developing on-premise cloud computing models will face when trying to migrate applications to or from off-premise cloud computing models: portability that is more than “skin” deep. It’s the same problem implementers face when trying to normalize infrastructure services: disparate vendor implementations of APIs and control planes make it impossible today to migrate easily between two like solutions because the services provided and thus integrated into the cloud management framework that enables automation are as different as night and day. If your on-premise cloud is integrated with your Load balancer to provide elastic scalability and you want to move to an off-premise cloud provider you can:

1. Find a cloud provider that also uses that load balancer (and is willing to let customers integrate directly)
2. Use a virtual network appliance version of the load balancer when deploying off-premise to enable the integration to continue working as is
3. Use a physical-hybrid solution
4. Employ off-premise cloud as a virtual private extension of your data center and continue to leverage your existing infrastructure
5. Rewrite the integration to take advantage of whatever solution your chosen cloud provider has available, accepting that you might lose functionality in the process.

This is because the services upon which the integrations are built are not portable (just like the services available from PaaS vendors for data, messaging, and other traditional application integration points). They are not mobile; they are not interoperable. The portability offered between PaaS implementations now – and likely for the foreseeable future – is only skin deep.

Now don’t get me wrong, this announcement is certainly a step in the right direction. After all, Spring developers will now have more options and more options is good. And for many organizations cloud “lock in” isn’t the problem some might think it is. After all, most organizations standardize on a development language and environment, a la “we’re a Microsoft shop” or “We’re a Java shop” or “We only deploy atop IBM WebSphere”. The difference between the two is subtle but has the same effect: lock-in to a particular environment. The difference is in who makes the choice: the vendor or the customer. If the former does it, it’s wrong. If the latter does it, it’s a choice. 

The announcements also don’t go into a lot of detail, and it may be the case that VMware, Force.com, and Google will provide the means by which these proprietary service offerings in fact will be “portable”, even if only via an automatic refactoring mechanism. As it stands, this announcement appears to be furthering the goal of cloud/application portability. It allows an albeit limited choice of environments, but it is still a choice all the same. But does it really further the goal of cloud or application portability?

I guess it really depends on how you define “portability” and whether or not you buy into the additional “services” offered by the respective PaaS offerings.