The Perception Risks of Multi Language PaaS

Over the past year or so I’ve become more excited about PaaS and what it means for the future of technology. In my mind, it seems that teo things are going on in the cloud stack. At the lower levels of the stack, IaaS is becoming commoditized and rapidly entering a race to the bottom where companies compete on price in a largely undifferentiated marketplace.

At the top of the stack is SaaS, an eminently useful sort of a beast but one which doesn’t have the degree of flexibility, scope and breadth to really be the uber play – sure SaaS vendors will make squillions of dollars selling apps – but salesforce and other enterprise SaaS vendors have shown that platforms are the way of the future.

Which got me thinking about PaaS and where it’ll go in the near future. I’ve already written about my view that PaaS will become bifurcated between iPas and aPaaS which I describe thusly;

  • 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.
  • 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.

Which brings us to a growing trend wth PaaS providers – that of supporting more and more languages and frameworks.

First up Heroku, originally the uber PaaS for Ruby/Rails developers – in recent times they’ve rapidly broadened their offering, they now support Node.js and Clojure and Java.

Then the other day it was the turn of AppFog who, very indicatively changed their name form PHPFog at the same time as raising another $8M in funding. At the time of announcing the raising, CEO Lucas Carlson indicated that the money would be used to broaden language and framework support, and that they’d soon support “Node, Ruby, Python, Java, .NET, and more”.

It’s exciting times for PaaS players as they race to be the broadest, deepest player – but I wonder if this headlong rush to be everyone to everything isn’t going to impact on what their developers think of them. Take for example Heroku – much of its success has been down to the fact that Ruby developers feel a kindred spirit with Heroku – that developers and platform creators together create the best offering for what they believe is the best/most agile/coolest language. It’s kind of another take on the coolest café in town situation, when that café decides to become a Starbucks franchise… things take a turn for the worse.

I wonder if this new breed of uber-platforms, trying to be all things to all people dilute their brand value and perception… time will tell I guess.

5 Comments
  • Interesting post, I’ve been thinking about something since I listened to a podcast about the extensibility of Cloud Foundry (it might of been theCloudcast.net).

    If you end up with a PaaS which can literally do anything, what’s going to stop your development teams from fragmenting back into the “old school” way of each team having their own bespoke (or at least rare) technology stacks, with all the attendant issues surrounding that stack – things like ongoing support, knowledge transfer, shared learning, all those kind of things become much harder when anyone can just throw a new technology into the mix.

    Of course, this is the kind of thing that architecture and design teams are meant to avoid, but give that it’s done so badly today, I don’t see that changing much in a world of extensible PaaS.

  • Ben – perceptive as usual. I’m wondering about your thoughts on CloudFoundry (the hosted service and the open source technology). With its support of Ruby (Rails, Sinatra), Java/JVM (Spring, Groovy, Grails and Scala) and Application Services like RabbitMQ, MongoDB, MySQL, and Redis), this PaaS layer is rich and diverse. I know of large deployments depending on CloudFoundry even at this early date and have heard of no show-stoppers. Because it is Open Source (so far) I’m more amenable to it than to the proprietary force.com, for example, PaaS offering.

    Also, enStratus has demonstrated the ability to manage automatically CloudFoundry on top of many IaaS layers, the most interesting to me being OpenStack.

    Will CloudFoundry + OpenStack become the defacto production environments going forward? With vigorous community participation and corporate investment in both of these Open Source projects, I believe the answer is: it’s inevitable.

    Thoughts?

    • Robot – cheers for the comment. WRT your question – it’s hard to say at this point what will become the dominant player at either IaaS or PaaS layers – but I really like what both CloudFoundry and OpenStack are doing and wouldn’t be keen to bet against them…. but as I said, early days yet…

  • Very important angle, how cool / leading edge is it?

    A whole lot of the software dev industry is driven by that question. The problem being that sooner or later Ruby won’t be cool anymore either :-) In fact Rails is a bit passe in my book.

    Similarly, you don’t want to be doing Agile anymore, it’s all Scrum.

    You wouldn’t want anyone to hear that you are using Git for source control, Mercurial or Hg all the way baby (let alone Subversion or TFS, ooh the thought).

    You wouldn’t dare tell anyone you are doing TDD anymore, its all BDD…..

  • You didn’t mention one of the most interesting iPaaS around Google’s App Engine (GAE). Supports Python, Java (and a whole lot of JVM languages Scala, Groovy etc.) and Go.

    There is also an open source clone of GAE called AppScale which Google is contributing to.

Leave a Reply