What ‘flavor’ is your PaaS?
Posted by Alex Chriss on November 9, 2008
This afternoon I was reading Dion Hinchcliffe’s great post on Building Modern Web Apps, and different product delivery models. It struck me that choosing the right Platform-as-a-service could be considered a component to your product delivery choice. So I did a little digging and found Tim O’Reilly ask whether there were advantages in choosing different PaaS options. Well, yes, I think there are big choices to be made in choosing where to build your next web app.
Simply put, as a developer, you have a choice in “flavors” – (“PaaS flavors” as a term lifted from a panel presentation Allistair Croll did at Web 2.0)
There seem to me to be three flavors of PaaS:
1) Pure platform – The tools needed to develop and host an app (Bungee, Google App Engine) [Monetization is likely exclusively through usage fees]
2) App-centric platform – The same as above but focused around a specific application (i.e. Force.com) – Advantage is that you can leverage an anchor tenant’s data and customer base to sell your app. Disadvantage is that you’re tied to the anchor tenant – for good & bad [Monetization through selling more of your anchor tenant, usage fees, and/or rev share]
3) Market-centric platform – Pure platform but with a specific market focus (i.e. Intuit Partner Platform – IPP) – Advantage exists only if the platform has durable advantages the developer can leverage in the market (i.e. brand, data, customers, channel) [Monetization through usage & rev share]
There are also different components that make up a “platform” and the importance of those components differ based on the flavor of the platform. For a pure platform, an end-to-end solution for developers is critical – otherwise there is very little value.
For an App-centric platform, having a developer build an app that ties directly to their anchor tenant – extending its value – is critical – The more apps, the stronger the anchor tenant becomes.
For a market-centric platform, the real value to developers is in the durable advantages – so some of the specific components can be “optional.” If developers prefer to build their app on a Pure-platform, that’s fine, as long as they expand the value of the market (note: network effect) – in this case, you lose utility charges but still have revenue share
The flavors of PaaS overlap and there are offerings that try to be multiple flavors, but I wonder if you always default to your core? Force.com is trying to be all three, but will it always default to its core app-centric model? IPP is also try to be all three – as it matures, it will be interesting to see where its true core is.