Friend and one-time colleague Krishnan Subramanian posted recently his view of the different ways PaaS products can be differentiated. Very briefly, Krish classed products in three distinct categories;

  1. Traditional PaaS models (push your app to the PaaS and all the underlying stuff is taken care of). Examples – Heroku, Google App Engine, PHPfog
  2. The Amazon model (package the PaaS but allow devs to get their hands on the underlying infrastructure). Examples – Amazon Beanstalk, Azure VMRole
  3. Federated PaaS (a federated ecosystem at the PaaS layer). Examples Cumulogic and VMware CloudFoundry

I’m not sure the battle lines are quite so distinct, but hats off to Krish for trying to show the continuum that exists here. I wanted to specifically reflect on the recent changes that Heroku rolled out, and what it means for their future direction, especially given the fact that they’re now owned by staunchly enterprise focused Some of the specific changes Heroku rolled out include;

  • New process model with support for background processes
  • Profiles for fine grained control over the processes
  • Logplex, support for logs (not just the logs for apps but also for the infrastructure underneath)
  • Automatic language detection upon deployment
  • Full Node.js support
  • Ruby 1.9.2 support
  • Ability to configure language using Procfile
  • Full process isolation for better security and performance

I spent some time talking with a friend who is deeply involved in developing on Heroku – his perception is that the new functionality is highly relevant to the technical critique they’ve been facing – specifically at an enterprise (read robust) level. In his words, the best way for a web app to truly scale is to introduce both caching and a worker queue – rather than just scaling by throwing more resource at it, far more efficient to better harden the architecture before simple upping the resource intensity. The ability to handle events, tasks and discrete quantities of work on a particular queue all helps drive the efficiency of an app BEFORE simply throwing more resource at it – fine grained control of prioritization answers the needs of developers who, be it through desire or necessity, want to deal with the inner workings of their application.

In his post, Krish contends that;

Heroku might be attractive for SMEs because of Salesforce’s push but I don’t see them making a big impact on the large enterprise segment

After talking with Abhinav Keswani from boutique development house Trineo I’m not so sure – the ability to specify functionality at a more granular level, the increasing robustness of a platform that ongoing investment by salesforce can bring, and the increasing uptake that the heightened awareness will no doubt bring will all prove to be factors that drive towards increasing enterprise adoption. It seems to me that this increased functionality sees Heroku play in both the traditional PaaS and Amazon models that Krish defined in his post – this fact should see Heroku become a popular choice.

I’m going to go out on a limb here and move on rom Krish’s PaaS categorization and suggest something different. I see the industry rapidly moving two distinct ends of the spectrum;

  1. Infrastructure PaaS (iPaaS maybe?) which is where Heroku, Amazon and Azure play, is all about giving developers raw infrastructure but with the addition of modular and tunable functions. This is where things like message queues, different workers, data stores and the like come in. As Keswani pointed out, in the early days of PaaS there was this perception that it provided a sort of panacea, a “throw your app at it and it works – magic” approach. The reality is different and for hands on developers building in an infrastructure – centric way, a desire to delve deep down into the different infrastructural aspects its important.
  2. Application PaaS (aPaaS?) is a approach where the platform is very data centric and is really tuned around allowing developers to build data-centric applications and then have all the underlying infrastructure fully managed. Keswani gave me an example of an application that Trineo is building that strongly leverages this data-centric approach. While is quick to say hat is way more than CRM customization, it’s a fair comment to say that is about data-centric design, as opposed to nuts and bolts infrastructure.

So as I see it PaaS is going to move to these two distinct ends of the spectrum more and more in the time to come. The future, as my title said, is indeed bifurcated.



Ben Kepes

Ben Kepes is a technology evangelist, an investor, a commentator and a business adviser. Ben covers the convergence of technology, mobile, ubiquity and agility, all enabled by the Cloud. His areas of interest extend to enterprise software, software integration, financial/accounting software, platforms and infrastructure as well as articulating technology simply for everyday users.

  • Hey Ben,

    The entire premise of my article is different from what you intend it to be. It was to show how different application-neutral PaaS platforms are evolving. If we have to differentiate PaaS vertically, there are many layers to it including business PaaS like Orangescape and Zoho Creator. My post was not about the entire PaaS stack.

  • PaaS won’t absolve coders from doing a solid job. This includes getting their workloads working as efficient’y as possible

  • Ben, it does seem like you and krish took different angles and I get them both, except … In your categorization, where does CloudFoundry fit in?

    • CloudFoundry is down in the iPaaS neck of the woods.. right now it is anyway….

      • Yeah, you and krish are definitely taking difference angles. His is the more traditional PaaS model (horizontal within the paas layer). Yours is more vertical and hints at the blurring of the lines as AWS adds more and more PaaS features to their IaaS stack

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.