I believe that some style of PaaS is the long run. But I’m also coming to believe that pure-play public PaaS — which is, the Herokus and Google App Engines of the realm — are doomed so far as serious deployments go. They’ll be the DreamHosts of tomorrow, great for folk spending $10 a month or less on a small website, but essentially ignored by people with serious business needs. The exception: Microsoft’s Azure, which, as a “full stack” provider, can meet the danger- and regulatory-driven patching requirements of these serious businesses.

The downfall of pure public PaaS is that, from a cloud security and risk perspective, it is a far 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 ordinarily will make contractual commitments about the way 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 would not develop or directly support — and over that you, as a customer, do not need complete control, either.

A touted “benefit” of PaaS is which you should not have to fret about installing/configuring/patching the software for your stack. But that sword cuts the wrong way pretty badly when you think about the chance, security and compliance implications of handing responsibility for software bug fixes and with the intention that updates don’t break compliance or other obligations off to a corporation that does not develop or control the software (we discuss the compliance conundrum in far more depth in our “Audit Fail” cover story).

And the chance picture gets even bleaker for Heroku due to the fact that it runs entirely on Amazon’s hardware.

Here’s ultimately an actual 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’s going to wait until customers manually accept changes. Within the former case, upgrades have the aptitude to wreck applications and compliance, since the PaaS provider isn’t the developer of the patched software and can’t control or guarantee the standard of the patch (see, as an instance, the tale 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). Within the latter case, the PaaS provider is pushing a responsibility at the customer that undermines one of many key selling points of PaaS: “You do not have to fret about configuring and patching software.”

Fundamentally, because no vendor goes to take responsibility for — and nobody is actually in charge of — to ensure that patches are installed place promptly and guaranteeing that they will not break your applications, you do, in reality, ought to take control of patching. If so, why not only use IaaS?

PaaS vendors may figure, just sell to organizations that do not 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 cannot be ignored (see Adrian Holovaty’s “Why I Left Heroku” for an example).

Indeed, i suspect the sole remaining market question within the PaaS world is whether or not PaaS-enabling software or cloud configuration management software would be more dominant. Briefly, pure public PaaS is doomed — with one notable exception.