The spread of enthusiasm for cloud computing seems unstoppable. Cloud computing -- a term that was unknown prior to 2007 -- has been named by Gartner as the number one priority for CIOs in 2011. One cannot recall a technology development that has gone from unheard-of to a key role in IT plans so quickly. So why has this unprecedented fervent cloud furor come to pass?
One way to approach understanding this phenomenon is to mimic the medical process, in which examination of the patient's condition is first performed, followed by diagnosis, and then treatment via prescription.
The examination of facts is undeniable. Every IT organization extant suffers from the following complaints: Endless waits for provisioning, capital invested and then used at less than 10% of capacity, and inability to cope with the growth brought about by cascades of new data, attachment of new devices, and creation of new applications designed to enable collaboration within and between organizations. Clearly a malady is overwhelming business-as-usual IT.
Turning to diagnosis, it's obvious that current operational and organizational models were developed for a much smaller scale, in which the cost and low productivity of manual provisioning were acceptable, in part because there were no alternatives. Today, however, lack of automation now threatens the ability of established IT organizations to survive.
Consequently, the prescription most often proffered to IT organizations is cloud computing, which, overlaying the existing physical infrastructure with an automation software framework, appears to be just what the doctor ordered. And, indeed, CIOs are now eagerly reaching for this medicine, though they are perhaps unsure if the vendor is offering a magic potion or a harmful nostrum.
The remedy most often selected is a private cloud computing infrastructure, despite the potential side effects present (as I wrote about last week).
But what happens after you swallow the pill? In other words, once you've committed to cloud computing and have an environment available, what do you do? Turning away from our extended medical metaphor, here are some action steps to take:
1. Standardize your offerings.
Part of the inefficiency and high cost of the current mode of operating IT is the "have it your way" responsiveness of most IT organizations. Customization is the enemy of automation and efficiency, so reduce it.
Create a standard set of pre-allocated virtual machines that a developer can choose among. A service catalog approach is exactly right here. We recommend mirroring Amazon's configurations: small, large, extra large, etc., with the same amounts of memory and storage. (Apparently, Cisco agrees with this recommendation, as it announced its intention to acquire newScale, a service catalog provider often used to manage standard catalogs of cloud offerings within corporations).
2. Create pre-packaged software stacks.
In addition to standardized virtual machine configurations, enriching those configurations with pre-packaged software stacks offers several benefits. First, it moves the organization toward additional standardization. When a developer can get started more quickly rather than having to spend time installing and configuring software components, he or she is more likely to develop solutions aligned with approved software stacks.
Second, offering pre-configured software stacks reduces errors from misconfiguration, always a good thing. Third, and by far the most important, it raises developer productivity. It can't be stressed enough, offering self-service virtual machines and storage is only table stakes. The pace of innovation Amazon is providing to ease developer use of AWS is amazing, and providing raw compute capability in the face of higher productivity alternatives is a recipe for being ignored. Amazon is quickly assembling a PaaS set of components, so don't believe your basic cloud computing will be sufficient going forward. Start evaluating how to extend your infrastructure to provide even higher developer productivity.
3. Integrate the new cloud environment into existing processes.
I wrote at length last week about the prospects for coupling cloud development into existing operations processes. There's no doubt that it's a challenge -- but there's also no doubt that it must be done for any hope to exist of directing developer efforts toward internal cloud environments. Failing to provide an easy way for developers to put their cloud applications into product is, in effect, communicating that the organization is not fully committed to cloud computing.
And developers are the scouts, so to speak, for application groups. If developers conclude that there is not a congenial home for their cloud applications, the application groups themselves will soon be looking elsewhere.
4. Market the offering.
It's not enough to create a cloud computing environment and assume that application groups will learn about it and adopt it. IT is moving from a quasi-monopoly supplier role to one of a number of acceptable options. Gaining developer commitment and use is crucial, and repeated marketing is part of getting it.
This is not a world of "build it and they will come." It may be unpleasant and seem somewhat demeaning to put on a marketing hat, but that's better than sitting in a meeting trying to justify a large infrastructure expenditure that's sitting unused.
5. Provide training.
It may seem that this post has been praising developers, and, indeed, some lionize the position developers hold in the cloud computing world; however, in our experience, many, many developers do not comprehend the new application architectures required to create cloud computing applications. The same is true for operations personnel -- they fail to understand how to provide just-in-time resources and to manage applications with constantly shifting topologies and highly variable loads.
Providing training can ease adoption for all parties involved, and has a high return on investment. The challenge is to get the appropriate training for each role -- developers need training on how to integrate applications into the cloud application management framework, while operations personnel need to learn how to operate an integrated and automated hardware and software aggregation. It's impossible to overstate the change that cloud computing imposes on existing practices, so don't shortchange your personnel by failing to give them the tools to succeed.
An Unusually Fast Platform Shift
In some ways, these recommendations are no different than those put forward to help IT organizations cope with the shift to client/server or the Internet. The difference is the pace of change. IT organizations are moving forward with cloud computing initiatives much, much more quickly than any previous platform shift. As I noted at the beginning of this piece, that speed reflects how poorly the current mode of computing is working.
Thinking that the job is over once the new whiz-bangy cloud infrastructure is in place is misguided. Only by surrounding the technical initiative with a corresponding organizational effort will cloud initiatives have any chance to prevail.
Bernard Golden is CEO of consulting firm HyperStratus, which specializes in virtualization, cloud computing and related issues. He is also the author of "Virtualization for Dummies," the best-selling book on virtualization to date.
This story, "Five Key Pieces of Advice For Cloud Rollout" was originally published by CIO.