Platforms as a Service Revisited

In September 2007, Marc Andreessen wrote a thought provoking blog post describing a way to categorize different types of Platforms as a Service (PaaS). Over the years we’ve often made use of Andreessen’s levels within our Engineering team as a convenient way to discuss how we want our own platform to evolve.

So I was surprised when I went looking for that article the other day and it was nowhere to be found on Andreessen’s blog! Fortunately I was able to rescue it from oblivion thanks to the internet archive. I’ve also uploaded a PDF of the article to Scribd.

Andreessen’s premise is that there are three levels of internet platforms (the term Platform as a Service didn’t exist back then):
  1. At level 1 a platform is essentially a series of APIs in the cloud (another term that had yet to make its appearance) that app developers can leverage in their own apps.
  2. The prime example of a level 2 platform is Facebook. In addition to the APIs it makes available, Facebook also gives developers a way to embed their apps into its user interface.
  3. A level 3 platform achieves something the other two levels can’t: It runs developers’ apps for them. Examples here include (’s PaaS) and Andreessen’s own Ning.

As the levels go up they become easier for developers to program on and manage. A company working on a level 3 platform shouldn’t need to worry about hardware and operating systems. The categories aren’t perfect though: Amazon’s Web Services offerings are clearly level 3 (they run your code) while forcing you to still manage a virtual infrastructure.

That said, many platforms do fit the model well. Thousands of companies offer APIs and therefore qualify as level 1. Platforms such as Google App Engine, Microsoft Azure, Heroku, EngineYard, etc. all offer flavors of level 3, some “purer” than others, I.e. with more or less hardware/OS abstraction.

At RelayHealth we put a number of APIs at our partners’ and clients’ disposal. Some are web services, others rely on healthcare specific protocols such as HL7 or CCD riding on top of a variety of communication channels.

Our approach to level 2 turns Andreessen’s definition inside out: instead of embedding third party apps into our UI, we make it easy for them to customize and embed our modules into their applications. This is important to many partners as building features like ePrescribing themselves is prohibitive. By providing these capabilities we enable our partners not only to deliver key features to their customers but also complete their EHR certifications (vital so their clients qualify for federal incentives).

Regardless of your approach, if you’re building a whole platform or some simple APIs, Andreessen’s article is worth reading.

Web API Lifecycles and Hypecycles

I've long been fascinated by the explosion of APIs over the past years, captured by the excellent ProgrammableWeb site.

Curious about how categories were evolving over time, I mined ProgrammableWeb's index for interesting patterns. I focused primarily on categories with at least 50 APIs, dividing them up into semesters from the second half 2005 to the first half of 2010. One important detail to be aware of: the PW index includes the last modified date of the API, not its creation date. So think of these graphs as a measure of activity in a particular category. For example an API may have been created in 2006 but if it was updated in 2010 it will count towards that last bar on the graph.

So what's hot? Social APIs, unsurprisingly, show a feverish activity: every site is busy creating or expanding their offerings in this space.

Enterprise APIs too are seeing a lot of movement.

Encouragingly, so is Shopping. A harbinger of an economic turnaround, or just wishful thinking? :-)

What about up-and-coming API categories to watch? Of the ones with over 30 APIs Travel and Utility have seen the most movement over the last year and a half.

Here are the remaining 13 categories with 50 or more APIs. Other strong performers include GovernmentTelephony, and Tools. Categories in relative decline? Reference and Video