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].
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.
Page 2: The many layers of PaaS »
« Page 1: Redefining the PaaS landscape
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]:
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.
Page 3: Expanding the universe of PaaS »
« Page 2: The many layers of PaaS
For business people who just want to get going with an app to meet an immediate business need, there are the more situational app builders. These range from mashup platforms to simple, no-coding, business-friendly application designers. Last week, I predicted their demise at the hands of database.com, although it would have been more accurate to wait until the following day's launch of Siteforce and the updated Appforce, which are more in this space than the developer-focused database.com.
Irrespective, the smaller vendors who already occupy and serve this market felt they had little new to worry about. Most rightly feel that their platforms are more approachable for the average business user, whether because of greater ease-of-use, better specialization or more personalized support.
"We don't see this tool competing with us," said Treff LaPlante, president and CEO of PaaS vendor WorkXpress. "Bear in mind that we are absolutely dedicated to the pursuit of programmer-free tools."
Derek Cheng, director of products and marketing strategy at Longjump, took a similar view, suggesting that the Force.com platform has not been easy for users to pick up: "ISVforce, Appforce, and Siteforce are also 'rebranding' existing functionality, perhaps to make the entirety of the platform more digestable." Another differentiating factor for Longjump is its availability for third-party or on-premise deployment, introduced early last year.
"Our core offering has always been the point-and-click application builder," emailed Frank Zamani, president and CEO of Caspio, who went on to mention the more attentive support that more specialized vendors can offer. "It is certainly possible that at some point in the future an application builder can also be offered by big vendors, however, they will realize that this is a very service intensive business that large vendors typically are not very good at."
Zamani added a note of caution whether Salesforce.com will be able to sustain its traditionally higher margins with an offering like database.com. "In our view infrastructure is a commodity with intense price pressure," he wrote. "The value is in the intelligent solutions that zero in on a niche demand."
One final consideration to bear in mind when looking at cloud databases like database.com is the potential for completely removing one tier of the traditional web application architecture. One of the first emails I sent as I listened to the database.com announcement was to Eric Rubin, CEO of Dreamfactory, which offers a web client that talks to any cloud database, including Amazon SimpleDB, Windows Azure and now database.com.
A problem when using database.com in a conventional web application architecture is the latency between the database and an application server located anywhere other than the Force.com infrastructure. "Keep in mind, most database-webserver connections are not only local, but frequently folks try to put fiber connections directly between them," pointed out WorkXpress's LaPlante. "Replace a direct fiber connection with a web connection, and I think what will be seen is some apps where it will work great, and others where it won't."
One way to solve that problem is to remove the application server from the architecture entirely, and instead put all the application logic on the client and have it call the cloud database directly. There's no more latency than having the client call the application server, and for many applications you'll speed response times by having the business logic execute locally on the client.
This is an architecture Bob Warfield has recently been calling Fat Saas, and he suggests that database.com may make it a lot more commonplace. It's certainly an architectural choice that merits serious consideration and underlines the expanding universe of PaaS choices today.