In the light of Salesforce.com’s swathe of announcements at Dreamforce last week and other recent developments, it’s a good time to take stock of the platform-as-a-service (PaaS) landscape. What are the choices now available to developers and business people looking to build applications on a ready-to-run cloud platform? As part of this review, I’ll report back on how PaaS vendors responded to my prediction last week of a shake-out following Salesforce.com’s database.com announcement. [Disclosure: Salesforce.com part-paid my travel expenses to attend Dreamforce].
Avoiding lock-in
Earlier this year, I hailed the launch of VMforce.com as “the defeat of [Salesforce.com]’s hitherto wholly proprietary Force.com platform strategy.” The admission of Heroku into the Force.com family confirms that new strategic direction, both for Salesforce.com itself and for the PaaS industry as a whole. As I wrote back in April:
“VMforce.com is to SpringSource what Heroku is to Ruby on Rails; a high-quality, multi-tenant, operational instance of an open-source platform. These platforms are popular with developers because of the apparent lack of lock-in. In principle, you always have the option of moving to another provider or to an in-house stack. In practice, it may not be so easy; but the principle is what matters. At a stroke, Salesforce.com has opened up its proprietary platform to the mainstream market …
“VMforce.com now redefines the PaaS landscape — and heralds a huge shift in Salesforce.com’s own PaaS strategy. It’s no longer about battles between closed proprietary platforms. The battle now moves to two new fronts: between competing open source platforms to establish which of them become the mainstream cloud platform stacks; and between competing operational providers to define the dominant infrastructure frameworks.”
In an astonishing turnaround within the space of a year, Force.com has gone from being a wholly proprietary platform to being remarkable in its support for open-source code and frameworks. Developers now have the freedom to build their Force.com applications in code that’s theoretically portable from one PaaS provider to another, or to their own in-house infrastructure. Even though the avoidance of lock-in is more illusory than real, given the practical obstacles to actually transferring an operational instance from one platform to another, the die has now been cast in favor of PaaS standards that are not the sole property of a single provider (with the valuable side-effect that the influence of competition makes such solutions cheaper). When selecting a PaaS platform, the lesson is that you should always look for the option, if only in theory, to move to another provider without having to completely rewrite your application code.
At least this is what we used to call it in the pre web applications era. 
