I say paradoxically because each of them works for or represents a large technology company's cloud computing efforts, and one would think their role would motivate them to strongly advocate cloud adoption. So why the tepid enthusiasm? For a couple of them, cloud computing functionality is really not ready for prime time use by enterprises. For others, cloud computing is too ambiguous a term for enterprises to really understand what it means. For yet others, cloud computing doesn't—and may never—offer the necessary functional factors that enterprise IT requires. While I think the observations they've made are trenchant, I'm not sure I'm convinced by them as immutable problems that cannot be addressed.

I thought it would be worthwhile to summarize the discussions and identify and discuss each putative shortcoming. I've distilled their reservations and present them here. I've also added my commentary on each issue, noting a different interpretation of the issue that perhaps sheds a little less dramatic light upon it and identifies ways to mitigate the issue.

There are five key impediments to enterprise adoption of cloud computing, according to my conversations. I will discuss each in a separate posting for reasons of length. The five key impediments are:

Current enterprise apps can't be migrated conveniently. Each of the major cloud providers (Amazon Web Services, salesforce force, Google App Engine, and Microsoft Azure) imposes an architecture dissimilar to the common architectures of enterprise apps.

Amazon Web Services offers the most flexibility in this regard because it provisions an "empty" image that you can put anything into, but nevertheless, applications cannot be easily moved due to its idiosyncratic storage framework, meaning they can't be easily migrated.

Salesforce force.com is a development platform tied to a proprietary architecture deeply integrated with salesforce.com and unlike anything in a regular enterprise application. Google App is a python-based set of application services—fine if your application is written in python and tuned to the Google application services, but enterprise applications, even those written in python, are not already architected for this framework. Azure is a .NET-based architecture that offers services based on the existing Microsoft development framework, but it doesn't offer regular SQL RDBMS storage, thereby requiring a different application architecture, thus making it difficult to migrate existing enterprise applications to the environment.

According to one person I spoke with, migrating applications out of internal data centers and into the cloud is the key interest driver for clouds among enterprises; once they find out how difficult it is to move an application to an external cloud, their enthusiasm dwindles.

I would say that this is certainly a challenge for enterprises, since if it was easy to move applications into cloud environments, quick uptake would certainly be aided. And the motivation for some of the cloud providers to deliver their cloud offerings in the way they do is difficult to understand. Google's commitment to Python is a bit odd, since Python is by no means the most popular scripting language around. Google sometimes seems to decide something is technically superior and then to insist on it, despite evidence that it retards adoption. With regard to Salesforce, I can certainly understand someone with a commitment to the company's main offering deciding to leverage the force architecture to create add-ons, but it's unlikely that an existing app could be moved to force.com with any reasonable level of effort; certainly questions about proprietary lock-in would be present for any enterprise that might entertain writing a fresh app for the platform. It's quite surprising that Microsoft would not make it easy for users to deploy the same application locally or in Azure; while the Azure architecture enables many sophisticated applications, the lack of ability to easily migrate will dissuade many of Microsoft users from exploring the use of Azure.

On the other hand, a different architecture than the now-accepted enterprise application architecture (leaving aside that current enterprise architectures are by no means fastened upon one alternative, so it's not as though the choice were between one universally adopted enterprise architecture and a set of dissimilar ones) doesn't necessarily mean that it is deficient or even too difficult to migrate an application to. It might be more appropriate to say that there is a degree of friction in migrating an existing application; that degree varies according to which target cloud offering one desires to migrate to.

Certainly it seems well within technical capability for someone to develop a P2C (physical to cloud) migration tool that could all or much of the technical effort necessary for migration; of course, this tool would need to be able to translate to several different cloud architectures.

Even if an automated tool does not become available, there is the potential for service providers to spring up to perform migration services efficiently and inexpensively.

Naturally, performing this migration would not be free; either software must be purchased or services paid for. The point is that this is not an insurmountable problem. It is a well-bounded one.

The more likely challenge regarding clouds imposing a different architecture is that of employee skills. Getting technical personnel up to speed on the requirements of cloud computing with respect to architecture, implementation, and operation is difficult: it is a fact that human capital is the most difficult kind to upgrade. However, cloud computing represents a new computing platform, and IT organizations have lived through platform transitions a number of times in the past. In these times of Windows developers being a dime a dozen, it's easy to forget that at one time, Windows NT skills were as difficult to locate as a needle in a haystack.

On balance, the lack of a convenient migration path for existing applications is going to hinder cloud computing adoption, but doesn't represent a permanent barrier.

Next posting: The challenge of risk: legal, regulatory, and business

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