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 previous posting about PaaS 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.
Sign up for Computerworld eNewsletters.