Published: 18 Feb 2014
It is hard to argue anymore that the IT landscape isn't changing. Cloud computing, both public and private, coupled with new ideals, like those of the DevOps movement, are leading us toward information technology that is faster, cheaper, and better meets the needs of business. The more I work with these new technologies and new ideas, though, the more I realize one thing: There is a commonly held misconception that all this change is about technology. It is actually all about people.
Technology is easy. It's the people that are difficult. Let's take cloud computing as an example. The USA's National Institute of Standards and Technology (NIST) put together a list of the five essential characteristics of a cloud computing service, no matter whether it's Infrastructure, Platform, or Software as a Service. The first characteristic, "on-demand self-service," is easily achieved. Any number of vendors -- VMware, Embotics, VMTurbo, etc. -- will sell you something that lets you create a self-service experience. Two other characteristics on NIST's list are like this as well: "broad network access" and "measured service." Given some money and some time, you can have all three of these. Many organizations stop here and exclaim, "Mission accomplished!" They think they have a cloud.
They don't have a cloud, though, because they didn't address the other two items on that list: "resource pooling" and "rapid elasticity." We talk about organizations as being siloed -- having insulated groups of experts that manage certain parts of our infrastructure -- but siloes cannot coexist with resource pooling. To have a true cloud, storage administrators used to provisioning storage carefully by hand for each server will need to hand giant pools of it over to a system that will do their work for them. The same holds true for network administrators.
System administrators are hit hardest, as "rapid elasticity" also means comprehensive automation -- no more building servers one at a time, no more configuring services by hand. Code it up once in a configuration management system like Puppet and deploy it thousands of times automatically, on demand, often when an automated monitoring system decides it needs more of something.
Resource pooling is scary to storage and network specialists, but rapid elasticity and the inevitable automation is an absolute horror to most IT professionals. They see it only one way: Once they automate operations, the business won't need them anymore. This, to a certain degree, is the point. It's taken us years to finally admit that humans aren't really good at certain tasks, especially repetitive ones. But the people doing those tasks right now cannot imagine what they'd be doing after the tasks are automated. They jump to the conclusion that they will be out of a job. So, consciously or not, people drag their feet, slowly sabotaging these automation and cloud projects to protect the way of life that they know.
In many ways people affected by cloud computing initiatives follow the five stages of grief: Denial that any change is necessary. Anger that someone thinks they aren't good at their job. Bargaining -- just let us keep doing things the old way, we'll do them better. Depression when these changes appear inevitable. An organization working toward cloud computing would benefit greatly from short-circuiting this process, skipping people directly to the acceptance phase. A little reassurance early in the project that automation isn't the end of the world, and that there are many more interesting problems for humans to solve, goes a long way to speeding the journey to cloud computing.