Three years ago September at its annual conference, Salesforce.com unveiled its Platform-as-a-Service (PaaS) offering Force.com. Three years later at the same conference, they announced the acquisition of Heroku, a Platform-as-a-Service startup. What happened in between may be instructive for the future of the cloud generally and platform-style offerings specifically.
If you’re unfamiliar with the PaaS idea, it’s simply explained. Platform-as-a-Service is a software abstraction layer that sits on top of more primitive cloud infrastructure. It’s roughly analogous to traditional definitions of middleware, in other words. While individual implementations vary, PaaS generally conflates a variety of individual software components into a fabric commonly referred to as a platform. Developers write to this platform rather than individual runtimes or frameworks, trading – in theory – choice for development velocity.
To date, the majority of developers have declined this trade. Infrastructure-as-a-Service (IaaS), which offers more basic application building blocks in a network available context, is overwhelmingly more popular than PaaS. This is partially attributable to predictable apprehension on the part of developers and enterprises alike: the introduction of new technologies is rarely a seamless process. The history of Software-as-a-service demonstrates this adequately [coverage]. Over a ten year period, hosted software jumped from niche to mainstream because of technical improvements in the user interface and available bandwidth, yes, but also because user fears thawed.
The concerns around PaaS are many, and by no means exclusive to Force.com. Most platform vendors are restricting developer choice. Google’s App Engine dictates database and language. Ditto for Microsoft’s Azure. Force.com, for its part, goes one step further and preselects database and language, both of which are proprietary. The Freedom to Leave, therefore, is substantially limited in platform scenarios. If you can’t recreate the cloud computing platform you’re using elsewhere, you become tied to that supplier.
Unless that supplier uses standard componentry.
Most reviews – developer and otherwise – of Heroku’s service focus on its ease of use. This is, however, an insufficient explanation for its traction amongst developers; as I write this, Heroku is currently hosting 107,912 applications. Even discounting that number heavily for the volume of Hello World class efforts, Heroku’s traction is impressive. Why? My guess is migratability.
Heroku began its existence as a push button Rails host with more or less standard technology. Code in Rails, instantiate via Ruby, deploy using Git. Even the subsequently added Add-On catalog (a cloud App Store-like model whose significance remains under appreciated) was dominated by replicable technologies: Amazon’s RDS, for example, is obviously available to non-Heroku users. As are Apigee, Cloudant, Membase, MongoHQ. and New Relic. Competitive platform components such as GAE’s Big Table, Microsoft’s Azure fabric or Force.com’s Apex/Visualforce languages, meanwhile, are not as simply substituted.
The perception amongst Heroku’s admirers, then, was that it was the best of both worlds: all of the strengths of PaaS (development speed, outsourced operations, etc) without its weaknesses (lock-in, proprietary componentry). Witness this comment on Hacker News from mark_I_watson:
A lot of people are saying this is bad news for developers. They may be right but really, one of the good things about Heroku is that there is no lock-in: seriously, it is simple to take any rack-based web app off of Heroku and other hosting options like self-managed EC2s, VPSs, etc.
I suspect that Salesforce will at least try hard to not [rock] the boat.
Whether that perception is accurate is debatable: even on identical platforms, migration can present challenges. What is clear is that Heroku deliberately built from standard pieces while its competitors relied on proprietary alternatives, and that developers advantaged the startup for that approach.
The primary question post-acquisition is what the larger significance of this transaction will prove to be. It’s important for Salesforce, of course. The value of the asset they acquired is dependent on their handling of same. If they impose Force.com’s philosophy on their new stable of developers, the impact will be negative. But if Force.com and the newly launched Database.com can borrow from what led to Heroku’s $212M valuation, it could be an inflexion point for its cloud business.
Not least because the larger context points to PaaS opportunity in 2011. M&A activity has pointed in this direction for some time. VMware’s August 2009 purchase of SpringSource [coverage], as an example, has in recent months begun to bear fruit from a PaaS perspective. More recently, Red Hat’s unheralded acquisition of Makara serves as an indication that the former sees realizable platform revenue ahead.
It is self-evident that IaaS is substantially more popular than PaaS at the current time. What’s open to question is whether this state of affairs is likely to be predictive for the future. Clearly the likes of Red Hat, Salesforce and VMware don’t believe it, given their respective investments in PaaS technologies. The economics of these investments are built on expected future returns, but the models employed vary widely from supplier to supplier. One model may be predicated on strong lock-in and commensurately high switching costs, the next might assume the reverse.
If the history of PaaS to date is any guide, however, successful models will not seek maximum leverage in lock-in. Shapiro and Varian may well be correct that “the profits you can earn from a customer – on a going forward, present-value basis – exactly equal the total switching costs.” But while ARPU is important, the more relevant question, from a PaaS supplier perspective, is customer volume: the cloud is not a model that favors a high margin, smaller customer base.
There is PaaS opportunity ahead; quite a bit of it. It doesn’t pay to bet against abstraction, remember. From optimizing compilers to garbage collecting runtimes to dynamically typed languages to web application frameworks to hypervisors, abstraction is a technology practice with a long tradition of rejection turning to acceptance. Whether Platform-as-a-Service will become another case study in the value of abstraction remains to be seen, but if it’s successful the acquisition of Heroku will likely be, in hindsight, a turning point.
One in which cloud vendors learned that the easier you make it to walk out the door, the more developers are likely to walk through it.
Disclosure: Salesforce paid for my T&E at the Dreamforce conference and is a RedMonk client, as are Apigee, Membase, Microsoft and Red Hat. Heroku is not, nor are Amazon, Google, Cloudant, MongoHQ or New Relic.
