After seeing a number of these promising beginnings turn into stalled launches, my friend concluded that some kind of organizational anxiety was preventing them from taking concrete steps. He believes a "defogging" service designed to help IT organizations clearly understand their options would help them move forward with confidence.
His experience mirrors my firm's. At speaking engagements, I interact with people who are intellectually convinced that aggressively moving toward cloud computing is necessary, but seem hesitant and even confused about what to do. In fact, you can see me discuss this in a conducted at a recent conference.
Upon reflection, the reasons for their confusion are obvious:
. Everywhere one turns, up pops another "cloud computing" solution. Each day brings new solutions along with old solutions disguised in new cloud computing raiments. The plethora of choices does not ease decision making. In fact, too many choices, as I wrote about a while back, actually makes people more likely to make no decision. Not understanding what is the right choice in an environment of many choices breeds disquietude.
Vendor overload. It's obvious that the landscape of IT is changing, and if you're an established vendor, your revenue stream is at risk. So you develop a cloud product and then turn every sales rep in the company loose with it. The relentless stream of vendors insisting that you need to listen to their cloud vision results in apathy and lassitude--and an intense wish the clamor would stop.
Fear of being wrong. If you're a senior IT executive feeling overwhelmed by the number of cloud computing options, not knowing which is the right one, and fearing that if you make a poor choice it could all go terribly wrong, with associated career damage--well, or course you plumb for more research, additional evaluation, more consultation with technology analysts. Anything to avoid making the wrong choice.
The result? An that creates stress, confusion and a refusal to make any decision. Nevertheless, the need to move forward is manifest. The tired legacy approaches aren't getting any more satisfactory, and the pressure from executive management isn't going to abate.
Let me share with you the recommendations we make to companies enduring this distasteful circumstance. We don't feel the uncertainty associated with this information- and vendor-overload can be avoided, but we do feel that steps can be taken to facilitate forward movement while protecting oneself against irredeemable missteps.
1. Start with a proof of concept. A low-risk, limited commitment experiment can validate the benefits of cloud computing and generate organizational learning without much downside. Knowing that the choice of technologies has a limited scope is very freeing, as it prevents the anxiety of "having to make the right decision."
After an acceptable deployment option is identified, whether internal or public, choose two applications as prototypes. One application should be legacy architecture, so you can determine the viability of transforming the installed infrastructure into a cloud environment. The second should be a web-based application, chosen to exercise scalability and elasticity, so the organization can learn about the long-term implications of cloud application architectures.
2. Implement limited, non-critical functionality. There's a reason new skiers start on bunny slopes, and it's an appropriate approach for cloud computing as well. An application that the business does not depend on allows a more measured perspective and evaluation. Conversely, if the first application "has" to run, one can be sure that problems will not be seen as educational opportunities, but rather as full-on emergencies, which is not conducive to organizational learning.
3. Circumvent cloud infrastructure dependence. Perhaps the best way to protect oneself from a poor choice is to implement in a fashion that insulates one's applications from direct dependence upon a particular cloud implementation. There are several techniques to accomplish this.
First, manage your application code for deployment flexibility. Design the application so that it encapsulates code and software component installation, thereby allowing substitution of specific cloud infrastructures.
Second, use vanilla code components and eschew the use of cloud-specific services. Read my for insights about the potential downside of leveraging a particular vendor's application framework. Instead, use components and services that are widely deployed, enabling you to migrate an application among several cloud providers.
Finally, don't grow too dependent upon your initial cloud provider's management console. There are a number of cross-cloud management tools and frameworks, and you should evaluate them to determine if one of them can avoid dependency and lock-in.
I'm not sure it's possible to completely clear the fog surrounding cloud computing today. Nor am I sure that it's wise to wait for it to dissipate. Usually, by the time the light becomes perfectly clear, much of the day has sped away, leaving you to regret being so slow to get going.
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.