Skip to content

Despite much hope, PaaS momentum hasn't blown the doors off yet

Touted at the next thing in cloud, Platform as a Service is receiving much attention now. While PaaS has been far from a failure, it hasn’t been a mega success…yet.

I’ve been talking with several people about Platform as a Service use recently: with all the vendors (and us analysts as well!) going on about how great it is, I’ve been trying to assertion both current momentum and ongoing developer desire. The point of PaaS is to make a developer’s life even easier: you don’t need to manage your cloud deployments at the the lower level of IaaS, or even wire together your Puppet/Chef scripts. The promise of PaaS is similar to that of Java application servers: just write your applications (your business logic) and do magic deployment into the platform, where everything else is taken care of. Pioneers like Heroku have certainly proven that out, initially. Still, aside from that big name in the PaaS space, I very seldom hear developers tell me they’re using PaaS: they still prefer to use the lower-level of IaaS. Indeed, it seems that for many developers, the IaaS layer and tools around it are “good enough” for mow.

Taking Stock

Coming across PaaS usage numbers can be difficult. First, if they report at all, companies typically you how many applications, customers, and/or developers are using the PaaS. Customers is perhaps the only metric that’s not suspect: a paying customer, after all, is a committed customer who, at the very least, is providing revenue to the PaaS provider. Applications can be totally bunk: how many of those are simple “Hello, cloud!” applications, dead applications, duplicates, etc.? Developers is even worse: a “registered developer” could just be someone filling out a form and clicking submit.

I spent some time back in January of this year to round up some numbers, and I’ve found some additional figures which slightly updates those January ones. For example, number of applications deployed on various App Engine, Heroku, and

{“dataSourceUrl”:”//″,”options”:{“fontColor”:”#fff”,”midColor”:”#36c”,”pointSize”:0,”headerColor”:”#3d85c6″,”headerHeight”:40,”is3D”:false,”displayRangeSelector”:true,”hAxis”:{“maxAlternation”:1},”wmode”:”opaque”,”thickness”:4,”mapType”:”hybrid”,”isStacked”:false,”showTip”:true,”displayAnnotations”:true,”dataMode”:”markers”,”colors”:[“#3366CC”,”#DC3912″,”#FF9900″,”#109618″,”#990099″,”#0099C6″,”#DD4477″,”#66AA00″,”#B82E2E”,”#316395″],”smoothLine”:false,”maxColor”:”#222″,”lineWidth”:2,”labelPosition”:”right”,”fontSize”:”14px”,”hasLabelsColumn”:true,”maxDepth”:2,”allowCollapse”:true,”minColor”:”#ccc”,”displayZoomButtons”:true,”width”:500,”height”:371},”state”:{},”chartType”:”AnnotatedTimeLine”,”chartName”:”PaaS Apps”}

Each of AppEngine,, and Heroku are at sub 300,000 applications deployed. Which, is a big number, sure. But how many applications are there in the world? It’s hard to know (and how many are just “Hello, world’s!” and Pet Shops), but:

With those baselines and the estimates of the number of applications in PaaSes, things look luke-warm for PaaS adoption currently.

When it comes to customers, Microsoft Azure and EngineYard are the only ones I can track down:

Check out the raw data for the number of developers, which is perhaps the least helpful figure: akin to tracking downloads in open source horse races.

Sentiment, anecdotes, and other fuzzy analysis

Overall, I don’t hear a lot of excitement about PaaS from developers I speak with. Most of them have used Heroku (I tend to skew towards people who would, though), but they seem to be doing “just fine” with a “build your own PaaS” approach. As one enterprise architect put it:

[My] ideal is we leverage Chef/Puppet and stick to IaaS systems whether our own internal VMWare cloud, a public AWS or OpenStack or Rackspace or whatever tomorrow brings. Scripting the build out of what we need. I think that is going to be the most portable from what I have seen. But we have to balance that against the time/complexity savings of being able to deploy to a CloudFoundry with “one line.”

I think the overall answer is “we don’t know yet.” We care about lock in. We worry about it. But I’m not sure we care enough to push us one way or the other.

You’ve got it all wrapped up there: flexibility and future-proofing vs. what you already have and productivity. As ever, they tend to be skitish about being restricted on which middleware they want to use. “What if I need to use node.js, or zeromq, or, I don’t know, Java?” they say.

These are all trade-offs, to be sure: to tautological, any technology choice means you’re using that technology and not others. The question for developers is how much flexibility they’ll have to add in what they need.

Offerings like Cloudfoundry seem to be addressing these concerns. The same EA said:

CloudFoundry is very intriguing to [our line of business] specifically from VMWare given our Spring heavy stack already. The idea of utilizing the open source version (or paid supported version) that we pull internal to our own VMWare stack could be very interesting. But again we need some more maturity in our [corporate IT] area [to start thinking along these “cloud” lines]. They are still relatively new (2 years) and are just maturing around how to support these various [programming models].

As another random data point, it’s notable that Accenture has a PaaS services offering now.

PaaS 3.0

Almost nothing works the first time it’s attempted. Just because what you’re doing does not seem to be working, doesn’t mean it won’t work. It just means that it might not work the way you’re doing it. If it was easy, everyone would be doing it, and you wouldn’t have an opportunity.
Bob’s Rules

Stephen O’Grady suggests, in email, that there’s three waves of PaaS, each learning from the past and getting better:

  1. Azure, AppEngine, – each a bit too limited and narrow. Too much lock-in
  2. Heroku – Stephen describes PaaS in this phase as “built from off the shelf parts and practices, these were the “same idea, but with an important differentiation with respect to interoperability and standards.” Slightly more open, if standard.
  3. Cloundfoundry (which I praised), OpenShift – these are, as Stephen says, “composed of not only standardized components, but each of which supports multiple runtimes.” I tend to see these more as “bring your own PaaSes”

Stephen closed out our email discussion with this:

In essence, then, I think there’s very solid upside in PaaS plays, assuming they’re copying Heroku’s formula rather than, say,’s. Because really, what most of them become is hardware backed language framework targets – think djangy, Heroku or nodejitsu. And we know from experience that frameworks are leading language adoption. While the timeframe of their traction remains unclear, I am bullish on PaaS for all of the above.

Check out more of his PaaS thinking in his 2011 predictions note.

Indeed, while PaaS adoption hasn’t been going gang-busters of late, it’s not really possible to write-off the idea yet. In fact, it’s probably a good idea to assume there’ll be more of it, even if we don’t exactly know what form it will take.

Disclosure: VMware, Microsoft, RedHat, Salesforce, and others are clients.

Categories: Cloud, Programming, The New Thing.

Tags: ,

Comment Feed

9 Responses

  1. Chef has liberated our environment from being locked in to a specific OS or platform by making it easy to deploy the same stack flexibly. That's not something we're prepared to give up for another walled garden. Chef let's us define the walls of our garden now, and get nearly the same "one button" Heroku-style environment.

    Jason J. W. WilliamsJune 30, 2011 @ 3:58 pm
  2. Great article. We're using both PaaS and IaaS and yeah, right now "roll your own PaaS" seems to be more functional and just as easy as the existing PaaS offerings unless you want to do very trivial things. Of course, some components of a larger system are trivial things, so I'm looking forward to better cross-cloud federation (and maybe network peering agreements!) so that I can put some bits on Google App Engine, some on Amazon, some on Azure, and some on random SaaS suppliers and have it all work right (I have parts in all these places now, but the integration is a pain).

  3. Thanks for adding in y’all experience!

    CotéJune 30, 2011 @ 6:08 pm
  4. Great post — I've been reviewing PHP Fog, with our WordPress blog as an Amazon IaaS to Amazon-backed PaaS test case.

  5. Do you really think Accenture's Application development service is PaaS?

    I consider them as service provider. In the above link provided by you, if you check specific services, they are saying that they can provide PaaS services on Azure, VMforce, AWS, GAE, etc..

    Nandavarapu KiranJuly 1, 2011 @ 3:54 am
  6. Nandavarapu: indeed, that's exactly what I think they're doing, "services" as in people doing stuff, not actual, running, software back "services" was in SOA, etc. 😉

  7. Here's a list of two dozen+ PaaS vendors and offerings …

  8. Nice analysis Michael.

    Prompted by someone else that read this post who argued the EC2 should be in the PaaS category, I learned that the new EB offering over AWS – it does does sound like a step closer for EC2 to move from the IaaS cat to PaaS. The strongest advocate I've read on this view is from Ovum, "Some view this second-generation as “IaaS-and-a-half”. Ovum disagrees. It is not a dilution of the notion of PaaS, but a logical evolution. The redefinition of PaaS as a layer on top of IaaS is the result of the commoditization and specialization that underpins public clouds."

    A couple of my own thoughts: a) EB is still a limited beta offering so once they pull this into GA I'll look again to see how it's changed evolved from it's current offering. b) I really like that they plan to go beyond Java support (e.g PHP, Ruby) – for me, this breadth of support for different frameworks/langs is what separates men from boys in the PaaS wanna-be space, and c) for EB, devs are "on their own when it comes to setting up the database back-end." I think the DB side here is a core component of PaaS definition.

    So, at what point in your mind would EC2 move to the PaaS cat, and if it did would it significantly alter the conclusion of your analysis?