Why IaaS Won't Happen At Most Enterprises

After speaking last week on a webinar about government cloud computing and doing some thinking-out-loud with colleagues, I've come to the conclusion that infrastructure-as-a-service will get bypassed by platform-as-a-service at most enterprises -- because infrastructure folks will continue to act as an impediment to progress.

The benefits of cloud computing are clear: Improved agility and efficiency through dynamic provisioning; and lower labor costs and more fault tolerance through automation. The private versus public cloud debate has been over for some time. There are use cases for each.

But getting IaaS into your enterprise probably won't happen soon.

[Find out what other companies are doing with the cloud. Read 3 Surprising Trends Among 'Pacesetter' Cloud Adopters.]

This is, of course, more of an organizational change management problem than a technology problem. A slavish devotion to current and past practices seems to override the interest in the outcome: Business units getting what they need in a more agile, less expensive, more reliable way. Are there technical difficulties in getting there? Of course! But there were difficulties in deploying the enterprise IT infrastructure we have now. Last I checked, overcoming those difficulties is a key reason IT pay is significantly higher than for many other disciplines.

Somehow, enterprise IT, like government IT, believes in the big lie of total control. The thought process goes: If something lives in our datacenter and it's supplied by our current suppliers, all will be well.

Wrong! Here's another thought experiment. You rely on an off-premises supplier. One slip by that supplier could cause significant enterprise-wide downtime. No, I'm not talking about a cloud service provider. I'm talking about your on-premises-software suppliers, all of which work off-site and all of which supply updates that you must apply to the software. As we all know, bad updates to enterprise software occur all the time. Do they cause the world to end? No. We deal with the problems that slipped by our QA process, and we adjust our process to make sure that these particular problems don't reoccur.

Why do we think that "the cloud" will be any different?

Business value bypass
Here's the key issue. The "supply chain," so to speak, of business value starts with a business partner who wants to improve something through business technology. That partner works with either an analyst or app dev to turn that idea into reality. While it can be incredibly valuable for a company to source a business-savvy analyst or developer internally, in most cases it doesn't matter where a business gets its infrastructure labor from.

The reality at most enterprises is that application developers who want to take advantage of the agility of cloud platforms are stymied by a mountain of arguments and existing (obsolete) policies about span of control. The infrastructure folks see their stuff working pretty darned well and they don't see the need to fix something that isn't broken -- from their perspective.

Roadblock workarounds
So, if infrastructure folks are getting in the way of creating business value -- and I think they are, although it might be unintentional -- here's what's going to happen. When creative, passionate business people want to get something done, they find a way around the roadblock and usually stay as far away as they can from the folks who put that roadblock up. They try something else.

And that something else is inevitably going to be platform-as-a-service. PaaS abstracts all of the infrastructure, such as virtual machines and storage, and focuses on the notion of a "container" for any given application, whereby the platform dynamically provisions the needed VMs and storage for the container where the app runs. Infrastructure is at the core of PaaS, but it's totally invisible to developers, which is just how they like it. (Infrastructure staffers will insist that hand optimization and monitoring of the underlying infrastructure is necessary, but this is like the transcriber insisting that word processing will never work.)

IaaS lovers put forth the notion of DevOps, whereby the modern IT pro is an application developer who's also interested in infrastructure, or vice versa. It plays to our romantic notion of the Renaissance Man, but it's unrealistic.

Most developers like to focus higher in the stack. They have no interest in orchestrating servers, or choosing between block and object storage. They just want to select an environment and deploy their app to a platform and have it scale up or down as needed. Thus, my sense is that most developers -- who, again, are the closest IT folks in the internal enterprise supply chain to business partners -- will choose PaaS for this reason.

During my webinar, I used the civic hackers at Code for America as an example of business change agents who have used PaaS. Why wouldn't they? They go into an organization, problem solve, apply technology and engagement strategies. No internal infrastructure needed! Lots of Code for America apps are hosted on Heroku (the handout for my webinar points to some of them).

If you're coming in as a tiger team to deal with business problems, why deal with internal IT's infrastructure when you can rent capacity cheaply? And why deal with issues such as virus protection, host intrusion protection systems, and so on when you can simply deal with a "container" for your app instead of having to think about virtual machines?

People tend not to believe that PaaS is as simple as it seems. And of course nothing is fairy-dust magic. But automation has gotten a heckuva lot better. In the same way that we no longer live in the world of "upgrading your RAID disk size means blowing away the array and restoring from backup," platform software has gotten pretty darned good and we can expect the level of sophistication to rise.

I still think there are niche use cases for IaaS -- disaster recovery for some legacy apps, train and test deployment of infrastructure that will tolerate being loaded into IaaS. But my observation is that the datacenter unions at enterprises want "the cloud" to look exactly like what they have today, factored for infrastructure staff's convenience, not the rest of the supply chain's. That's not going to cut it. The primary instigators of the supply chain of business value can and will bypass them.

Private clouds are moving rapidly from concept to production. But some fears about expertise and integration still linger. Also in the Private Clouds Step Up issue of InformationWeek: The public cloud and the steam engine have more in common than you might think. (Free registration required.)