Second, it's easy to underestimate the change necessary to operate an agile infrastructure. End-to-end automation carries implications well beyond installing a cloud software stack and declaring "open for cloud business." Just as it's traditional that new platforms accrete around old ones, it's also traditional for IT organizations to overemphasize technology and underrate people and process. The outcome of this situation is that the cloud application will suffer many problems when put into production as the operations group learns on the fly how to manage an automated, elastic application.

This scenario presents an existential challenge to the mainstream infrastructure operations organization and, indirectly, a threat to the financial underpinnings of the entire IT organization. In this scenario, developers attempt to use the private cloud but, for various reasons, find some element of the environment unsatisfactory and choose to develop or deploy in a public cloud environment.

An example of why this might come to pass can be illustrated by an example we ran into recently. In discussing cloud computing with an infrastructure manager, we described the need for resource user self service. The manager was fine with greater agility, he allowed, but the request for resources had to be forwarded to an operation administrator who would evaluate the request and, should it be appropriate, would provision the resources himself and then forward information back to the developer sufficient to begin using the resource. He really didn't understand the difference between true self-service and email-enabled resource requests. I wouldn't care to hear his response to the need for self-provisioning elastic applications directly provisioning resources in response to system load.

This response is typical of organizations responding to innovative developments (I last week and concluded that cloud computing is a disruptive innovation). When confronting a disruptive innovation, organizations commonly attempt to force-fit it into existing processes and assumptions -- usually unsuccessfully.