Platform as a Service, Portability and Mobility

In a recent entry Joe McKendrick wonders if current Platform as a Service (PaaS) approaches are really potential vendor lock-in opportunities similar to some SOA-based offerings. As he says, although PaaS ...

[...] essentially provides a data center on demand, with servers, storage, and middleware all hosted by a provider. But you don’t want to hard-wire your requirements into a single vendor.

Joe references another article from Lori MacVittie where she differentiates between mobility and portability in the Cloud.

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.

Lori states that recent announcements from various vendors are really about portability and not mobility, something which may not always be clear from the outset. Now of course there are some things that may always limit mobility within the Cloud, e.g., when you choose a specific language, such as Java, that some PaaS solutions may not support. However, as Lori indicates, there are other aspects of current PaaS approaches that may not be so obviously limiting to mobility.

[...] the use of proprietary platform services such as those offered for data, queuing and e-mail. [The recent 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. [...] Such platform services are proprietary. Closed. Non-portable. They are services that, once your application is dependant upon, you are “locked in.”

So users can get locked into these platforms, despite what they may assume. Of course this is a similar warning to Rich Stallman's back in 2008, but for different reasons, and as Tim Bray voiced at around the same time. As Stallman said back then:

Do your own computing on your own computer with your copy of a freedom-respecting program. If you use a proprietary program or somebody else's web server, you're defenseless. You're putty in the hands of whoever developed that software.

As Joe points out, however, these issues are shared with other software methodologies such as SOA (in fact as most readers will be aware, vendor lock-in has been a constant that dates well before SOA came on the scene):

The issues Lori raises have been the same issues the service-oriented world has been struggling with all along — that is, companies rely heavily or exclusively on a particular vendor environment, thereby limiting interoperability between silos, be they across the enterprise or between enterprises.

In recent years we have seen an increasing effort to standardize as much of technological SOA as possible, including the various WS-* efforts, SCA, JAX-WS and JBI. Given Lori's definitions, these standards address mobility and/or portability and in some cases interoperability. So a first step to addressing the vendor lock-in issue should be standards, but of course not too early because those standards tend not to be successful.