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 Amazon.com.
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 trade-off, Staten says. You need to weigh the advantages of using provider-specific technology against the vendor's vulnerability.
Take Salesforce.com, 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."
To determine a vendor's viability, Staten proposes doing in-depth research, asking the vendor to provide under a nondisclosure agreement information such as its cash position. He also talks to the venture capitalists backing the company about their commitment to it. In addition, Staten recommends asking references whether they're just dipping their toes in the water with a vendor or making a bigger commitment.
Serena Software's Bonvanie also advises companies to specify an exit strategy in their contracts. "The imperative is that you agree with your vendor on what the procedures are for abandoning their application, if needed," he says. For instance, how does data come out, and what is the vendor's involvement in making that happen? How much time do you have to get the data out after service nonrenewal?
In many of its contracts, Serena inserts escrows to regulate what happens to its cloud software vendors' source code if the vendors cease operations. Bonvanie says he has found that cloud vendors are more forthcoming about doing this than most traditional vendors.
It's also essential to set policies early on as to how your company is going to use the cloud and under what circumstances, Staten says. This is especially important when it comes to securing data in the cloud, which often requires customization by the user. "You have to do things above and beyond what the cloud vendor provides to be secure or compliant," he says.