It came from the cloud: The looming change in IT

PaaS is finally getting traction, and when it takes hold, the lives of developers will change forever

Guess what? PaaS -- the cloud platform to automate dev, test, and deployment of applications -- is back.

For years, so-called thought leaders including myself have run off at the mouth about how IaaS is more of a stopgap, and eventually everything will be SaaS and PaaS. After all, why should you lovingly craft each installation yourself? Why should you build your own PaaS on IaaS with Puppet? Instead, the commoditization of computing will enable you to treat everything as either an application or a resource. PaaS must surely triumph.

For three years, during what I call the “great PaaS pause,” it didn't happen. Now, according to Pivotal, IBM, and others, the switch to PaaS is finally starting to take root.

Everything that has happened before will happen again. In the late '90s, I worked for the IS/IT department in the American headquarters of a now defunct cellphone manufacturer. Andersen Consulting had the bright idea that everything should be run as a project and IT should bill for it, but lacked the corresponding idea that after a project is finished, the resulting software requires maintenance. 

Each project by each department tended to get its own server until the rack was full. Then we'd push back and ask if they might care to combine applications on servers. You see, we would buy Compaq servers left and right (all for top dollar because the procurement was outsourced to Price Waterhouse, which charged at least four times what I could get from CDW in one-tenth of the time), but real estate for another rack was at a premium.

No one wanted to share, of course, because everyone wanted their applications done yesterday and on the cheap. Development was expensive, but maintenance was free, so crapware was the corporate standard.

Within a few years this entire culture would be wiped out. Virtualization changed it rather dramatically. These crappy departmental stovepipe applications no longer had to get along; they would all have their own little sandbox to crash in, and no one but the users would care.

The VMs, however, still belonged at least tangentially to the departments that funded or requested the project and caused them to exist. IT is still largely the caretaker for them. Often, resources are purchased based on the number of VMs procured, and a huge amount of computing is wasted running another copy of Windows for the sake of faking that you having a separate server.

Consider what changes would occur if IT moved all internal applications to an internally managed private PaaS. There is one general price to providing the service of running the application. The incremental price for using resources should also scale with the business value of the application. Next, consider what this does to the games played around maintenance.

In the VM world, once the application is deployed in production, developers largely can blame IT for anything that goes wrong. Frequently, the folks in charge of the VM are also the ones who have to prove that the application is crashing because it has a bug. In the PaaS world, the developers have to prove the application on the PaaS which IT maintains is working. If there is a genuine issue with the components of the PaaS, then presumably more applications would be failing. The question of “was it the OS or the runtime or the app?” answers itself.

Consider what this does for the process of QA and development. While you may have a development versus a QA versus a production database, and you may have a few installations based on that configuration, there's no reason for ceremonial build-outs of different environments. Instead, containers may be configured with different security policies. Moreover, applications can be “promoted” to QA or stage or prod. They don't necessarily even need to be reinstalled, simply pointed at a different database.

But what about the public PaaS? Supposedly the new PaaS model will be “hybrid” for big companies concerned about moving things into the public cloud or who have too much data generated internally to make it cost effective. Ultimately, the public PaaS is less expensive and scales better and you basically outsource a lot of the monkey work that IT is forced to do. Instead, IT moves more to data stewardship, policy enforcement, and support.

PaaS will be every as much of a culture change as virtualization, if not more. Ultimately, this change will bubble out of IT and even change the way the business works. But first, PaaS will change the way we do everything in IT -- and almost certainly change the lives of everyday developers.