For years, pundits have predicted that platform-as-a-service (PaaS) will gain massive market share anytime now. That's thanks in part to the idea that, if you give a platform control over every bit of IT service management (not just orchestration), that platform will make automating tasks easy.

It's a nice theory, and there are plenty of reasons to embrace orchestration, as I discuss in this week's InformationWeek Tech Digest. But there's a yawning chasm between concept and reality, for two main reasons. First, web applications built with scripting languages like PHP, Python, and Ruby are really hard to platformize. Second, relational databases are really hard to orchestrate.

In the battle for PaaS market share, fortune has tended to favor vendors that work with languages that compile binaries that run on software virtual machines, like Azure and Apprenda (for .NET) and CloudBees and CloudFoundry (for Java). When you compile to a binary, you get really good encapsulation of all the supporting libraries (and corresponding configurations) needed for the applications. The PaaS system doesn't need to worry about stringing together a bunch of dependencies. It can simply load your binary and worry about a relatively small number of configurable options, mostly around the web server.

On the other hand, if you're using a scripting language like PHP or Python, you end up with a ton of dependencies on libraries that need to be installed. Your code will work with only some versions of the libraries, and a few libraries are sure to have been designed to be compiled on the server on which they're running. At that point, the PaaS has to deal with making sure the code is compiled for a particular server. Not much of a platform, really.

[For more on PaaS, see What Is Platform-As-A-Service? Experts Disagree.]

Relational databases -- which are used in the vast majority of web applications -- don't fit into cloud architectures very well, because they usually rely on a single master database server that must be available at all times for the application to function. Making changes on that database server will cause it to be unavailable for periods that are inevitably too long.

So even if you do have a database server running in a PaaS setup, you likely can't orchestrate changes to your master database node without taking down your application -- and more importantly, the PaaS just won't know enough to determine whether a particular requested change would take the applications down. Can we fail over a slave now and avoid dropping a significant number of transactions? Who knows?

In fact, the presence of PaaS as a layer between you and your database server makes administering the database more difficult than it would ordinarily be. That's because you actually need the fine-grained control over the database server that hosting it yourself provides.

Though the present remains fairly dim for PaaS, the future looks a bit brighter. I discuss why this is so in my PaaS Buyer's Guide, and lately we've seen the rise of Linux containers and Docker, a tool that makes it easier to embrace containers.

Containers bring two new benefits to the table: They offer better performance than virtualization, and they allow applications written in scripting languages to look a lot more like those written in .NET and Java as far as PaaS goes. With encapsulation and Docker, you build a Linux container (sort of like a binary meant to run on a software virtual machine) that runs your application. This container is fairly portable and can contain the configuration and other libraries that your application needs, allowing your PaaS provider to focus many more resources on things like orchestration, instead of handling application dependencies.

To some extent, the jury is still out on Docker, though the recent embrace of its functionality by companies from Amazon to Red Hat will likely drive increasing adoption over time.

As far as the database server issue goes, life still looks quite difficult for PaaS providers. The best path forward seems to be via databases that are cloud friendly on the back end while being completely compatible with standard relational databases on the front end (read: NuoDB), along with increased use of cloud-friendly databases (read: Riak). However, unlike with IaaS and on-premises services, the road ahead still looks long before we can orchestrate applications completely via PaaS.

SDN's disrupting networking, flash is disrupting storage, and DevOps is upending application strategies as companies such as Oracle, IBM, and SAP see decades-old revenue streams drying up. Share your data center reality in our InformationWeek State of Data Center Survey by June 6 and enter to win a 32-GB Kindle Fire HDX.