Cloud computing: Don't get caught without an exit strategy

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.

And 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 this setup. And the recent announcement that Coghead, maker of a cloud-based enterprise application development system, is shutting its doors 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 and author of an IT management and cloud blog. When people talk about lock-in, they often don't distinguish among the several cloud types that exist, each of which requires varying degrees 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,'" he says. "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."

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

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

Particularly with software and platform as a service, vendors use unique and proprietary interfaces, application programming interfaces (API) and databases. To take full advantage of the system, users or third parties need to program to those specifications to varying degrees. If they grow dissatisfied with the service, or if the vendor goes under, data and/or applications would need to be reformatted in order to switch providers or move it back in-house, 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 unique APIs you write to, or the unique configuration or composition of the application," Staten says.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email ARN
• Follow ARN on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark