I believe that some form of PaaS is the future. But I'm also coming to believe that pure-play public PaaS -- that is, the Herokus and Google App Engines of the world -- are doomed as far as serious deployments go. They'll be the DreamHosts of tomorrow, great for people spending $10 a month or less on a small website, but essentially ignored by those with serious business needs. The exception: Microsoft's Azure, which, as a "full stack" provider, can meet the risk- and regulatory-driven patching requirements of those serious businesses.
The downfall of pure public PaaS is that, from a cloud security and risk perspective, it's a much more challenging model than either software-as-a-service or infrastructure-as-a-service. With both SaaS and IaaS, you delegate security, availability and compliance concerns to a single vendor, which in most cases will make contractual commitments about how it will meet those needs. With non-Azure pure public PaaS, however, you're using a stack (Web server, Web framework, database server, caching servers, supporting libraries) that the PaaS vendor does not develop or directly support -- and over which you, as a customer, do not have complete control, either.
A touted "benefit" of PaaS is that you don't have to worry about installing/configuring/patching the software in your stack. But that sword cuts the other way pretty badly when you consider the risk, security and compliance implications of handing responsibility for software bug fixes and making sure that updates don't break compliance or other obligations off to a company that doesn't develop or control the software (we discuss the compliance conundrum in much more depth in our "Audit Fail" cover story).
And the risk picture gets even bleaker for Heroku when you consider that it runs entirely on Amazon's hardware.
This is ultimately a real Catch-22. A service like Heroku or Google App Engine can either automatically upgrade software packages (say, from version 9.2.23 to 9.2.24) without customer permission, or it can wait until customers manually accept changes. In the former case, upgrades have the potential to break applications and compliance, because the PaaS provider is not the developer of the patched software and cannot control or guarantee the quality of the patch (see, for example, the story of Ruby 1.8.7-p173 or Cloud Foundry's Tomcat upgrade; for a more detailed analysis of this issue, read William Vambenepe's oldie but goodie blog post). In the latter case, the PaaS provider is pushing a responsibility on the customer that undermines one of the key selling points of PaaS: "You don't have to worry about configuring and patching software."
Fundamentally, because no vendor is going to take responsibility for -- and no one is truly in control of -- making sure that patches are put in place in a timely fashion and guaranteeing that they won't break your applications, you do, in fact, have to take control of patching. In that case, why not just use IaaS?
PaaS vendors may figure, just sell to organizations that don't concern themselves with vendor risk assessments (hello startups!). That'll be fine until a critical application runs into problems surrounding patching or some adjacent issue that just can't be ignored (see Adrian Holovaty's "Why I Left Heroku" for an example).
Indeed, I think the only remaining market question in the PaaS world is whether PaaS-enabling software or cloud configuration management software will be more dominant. In short, pure public PaaS is doomed -- with one notable exception.