Mon, April 06, 2009 — Computerworld — When the IT world looks back at 2008, it will certainly remember the global financial crisis. But it will also likely link that time frame with the takeoff of cloud computing -- the engine behind more conferences, conversations and marketing collateral than seemingly any other technology in development today.

But amid all the hubbub about whether and how to get into the cloud, there's growing concern about how to get out.

Vendor lock-in is one of the primary fears expressed by IT leaders considering a move to the cloud. And the recent announcement that Coghead Inc., maker of a cloud-based enterprise application development system, is closing has exacerbated that fear.

Cloud computing is an architecture in which companies consume technology resources as an Internet service rather than as an owned system. Much of the fear of lock-in is caused by misconceptions, says John Willis, a systems management consultant who blogs about IT management and cloud computing. When people talk about lock-in, they often don't distinguish among the several cloud types that exist, each of which requires varying levels of commitment.

Moreover, he says, the degree of lock-in needs to be weighed against the advantages of using the system. "People wind up saying things like, 'The cloud is dead because of lock-in.' Well, what cloud are you talking about? I can give you five scenarios where lock-in is an issue and five others where it isn't," Willis says.

While some vendors debate whether lock-in exists, most agree that there are technical reasons for concern.

A lack of standards hampers the portability of data and applications between systems, says James Staten, an analyst at Forrester Research Inc. And though the popular hype implies that moving to the cloud doesn't require any heavy lifting, that's not true for some forms of cloud computing.

Particularly with software and platform as a service, vendors use unique and proprietary user interfaces, application programming interfaces (API) and databases. To take full advantage of a system, users or third parties need to program to those specifications to varying degrees. If they grow dissatisfied with the service or the vendor goes under, data and/or applications will need to be reformatted to be moved, which could be complex and costly.

"If you deploy to any cloud out there, some degree of your deployment is tied to the vendor, through the unique virtual machine or APIs you write to, or the unique configuration or composition of the application," Staten says.