Cloud Zone is brought to you in partnership with:

Ben Kepes is an analyst, and entrepreneur, an commentator, and a business adviser. His interests include a diverse range of industries from manufacturing to property technology. As a commentator he has a broad presence both in the traditional media and as an extensive blogger. He sits on the boards of a number of organizations, both commercial and not-for-profit. Ben is a DZone MVB and is not an employee of DZone and has posted 197 posts at DZone. You can read more from them at their website. View Full User Profile

On the Battle Lines of PaaS–The Future is Bifurcated

06.15.2011
| 2186 views |
  • submit to reddit

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 salesforce.com. 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 force.com 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 salesforce.com is quick to say hat force.com is way more than CRM customization, it’s a fair comment to say that force.com 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.

References
Published at DZone with permission of Ben Kepes, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)