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

Before you trust your business to the cloud, be sure you know how to get out.

A case in point is Microsoft's Azure Services Platform, which provides an operating system and a set of developer services to build cloud-based applications.

As Staten points out, with Azure, users write to a set of cloud services in a way that's different from writing to the same services deployed in their own environment. The calls to the SQL database, he explains, are different from the calls in Azure. To move to a different provider, users would have to understand how to translate those API calls into SQL Server calls, he says.

To minimize the complexity and cost of doing that, he says, cloud users should try to touch proprietary and nonstandard elements as lightly as possible. That's what RightScale claims to pull off with its management tools, which work with a variety of cloud infrastructure providers, such as FlexiScale, GoGrid and

As Crandell explains, its tools create an abstraction layer on top of these services, which effectively minimizes user reliance on proprietary technology and makes its tools portable across providers. "We shield companies from having to write a specific solution for, say, Amazon and then have to rewrite again for each cloud," he says.

What's more, Crandell says, RightScale's source code is available to users, so if they wanted to move away from RightScale, they could.

This approach makes Christian Taylor, CEO of MeDeploy, feel that his company's infrastructure product offers freedom of choice. MeDeploy offers a system -- based on Amazon EC2 and managed with RightScale tools -- that allows film distributors to build online ecosystems for distributing and selling films.

"If anything, [moving away from EC2] would be easier than [exiting] an on-premise system," he says. "It uses standard hardware, so if a competitor made us think of switching to a different cloud, we could just set up a whole other cloud system, load it up and then switch over."

The risk/benefit dance

Avoiding the proprietary aspects of a vendor's system really comes down to a risk/benefit tradeoff, Staten says. You need to weigh the advantages of using provider-specific technology against the vendor's vulnerability.

Take, which uses a proprietary programming language and APIs, he says. "Years ago, no one was writing custom applications in Salesforce or leveraging their APIs, because they didn't know if they'd be around," he says. "Now that they've been around 10 years and are well capitalized, those things are in high use."

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags cloud computing

More about Amazon.comAmazon Web ServicesCrucialForrester ResearchGartnerHubbubIntacctLinuxMicrosoftNetSuiteOracleSalesforce.comSAP AustraliaSerena Software

Show Comments
<img height="1" width="1" style="border-style:none;" alt="" src="//"/>