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.
Functional scope
It’s somewhat misleading to describe PaaS as a single category. There’s significant stratification, ranging from bare developer platforms like Heroku and Windows Azure all the way up to the likes of NetSuite SuiteCloud, in which the platform includes pre-built business objects tailored to a specific application type. This latter category has been expanding lately and there are very many players now emerging. Indeed, it’s almost de rigueur these days for a SaaS vendor to have a roadmap that opens out its application into a programmable platform that others can extend. Examples that have crossed my radar recently include [some of them clients, see disclosure]:
- RightNow CX Cloud Platform was unveiled in the summer as “the first platform to be purpose-built for customer experience.” This takes all the ingredients of RightNow’s customer service application — the knowledgebase, the various business objects for interacting with customers, the integration APIs — and allows customization to adapt to specific business processes or vertical needs, such as healthcare.
- Remote support vendor NTRGlobal unveiled a modular new platform in October with an API that allows partners to incorporate its functionality into tailored solutions. This applies the principle of PaaS to a very narrow functional scope.
- Now even enterprise software giant SAP is getting into the act, preparing to offer Business ByDesign in a PaaS model for partners to customize and verticalize.
And then of course there’s still Saleforce.com’s original Force.com, which remains available alongside the vendor’s newer and more open PaaS components. Force.com is a very mature, rich PaaS for those who want to build a classic forms-and-database SaaS application in the Salesforce.com mold.
Perhaps we need a new term — App-PaaS? — for this more functionally specific layer of application-platform as a service. In exchange for working within the functional constraints of the given platform, developers gain speed-to-market and the ability to focus on bringing their expertise to the business process layer rather than having to build the whole application infrastructure on the more toolkit-oriented vanilla PaaS offerings. This layer of PaaS appeals especially to SIs, small ISVs and solution providers who serve vertical markets. It does a require a leap of faith in the platform provider — the lock-in is terminal — but for many the payback of getting to market quickly is worth that compromise.
One word of caution for anyone evaluating these platforms is a reminder to look beyond the pure functional scope of the application they want to build and also consider the as-a-service capabilites and platform bandwidth of the underlying infrastructure. I’ve written before about the crucial importance of these elements for successful delivery of a viable cloud application built on PaaS.
Situational apps
(Cross-posted @ Software as Services Blog RSS | ZDNet)
[...] PaaS choices today (enterpriseirregulars.com) [...]
A comparative evaluation and scorecard of Oracle Public Cloud, IBM Application Services, Amazon AWS BeanStalk, CloudBees RUN@Cloud, RedHat OpenShift, VMWare CloudFoundry, Heroku, Google App Engine, Apprenda, Microsoft Windows Azure, and WSO2 Stratos PaaS across 7 categories and 80+ evaluation criterion can be found within the Selecting a Cloud Platform white paper published at http://wso2.com/casestudies/selecting-a-cloud-platform/
Let me know your thoughts. What criterion is required or optional?