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.
"You've made a choice to be involved in a certain ecosystem," notes Michael Crandell, CEO of RightScale Inc., a cloud infrastructure provider. "There are APIs and platforms in the cloud world that create a walled garden. You get the benefits of that garden, but you're also restricted."
Technical issues aside, lock-in is also an emotional issue, says René Bonvanie, senior vice president at Serena Software Inc., which provides a cloud-based application life-cycle management system and runs most of its own business on the cloud. He argues that data housed in traditional systems such as those of SAP, Oracle or Microsoft is just as locked in as data in any cloud system, but people are more concerned about cloud computing because the systems are not on their own premises.
"The common misperception is that because data is within reach, it's somehow more accessible than when it's remote," Bonvanie says. "But the reality is that it's like money: If it's in a vault, it doesn't matter where the vault is. It's locked up, regardless."
Exacerbating this fear is the immaturity of the cloud market, Staten says, adding that IT leaders can't help but ask, "When the shakeout comes, is this vendor going to make it?"
That's the case for Christopher Barron, CIO at CPS Energy. "We are very concerned about being locked into a vendor for a multiyear time period without knowing if they have the capability to serve us properly," he says.
For that reason, Barron is moving into cloud computing slowly, choosing certain processes that fit into this architecture without requiring him to commit the entire enterprise to the cloud. "By taking it in pieces, we can experiment, tune and adjust while mitigating a large financial commitment risk," he says.
"Vendor viability is less of a concern if you're using it for a short-term project like a promotional service or an application you want to test," Staten adds.
Staying Out of the Vault
Another way to approach the lock-in conundrum is to use Willis' rule of thumb: The higher you go in the cloud taxonomy, the higher the risk of lock-in.
With cloud storage, for instance, data is easily transportable because it's stored in Linux servers, he says, but cloud software and platforms come with nonstandard APIs, system calls and other proprietary technologies.
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 (see story).
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 environments. 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, Staten 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, RightScale's 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 adds, RightScale's source code is available to users, so if they wanted to move away from RightScale, they could.
Christian Taylor, CEO of MeDeploy, says he appreciates the flexibility of RightScale's approach. Hamden, Conn.-based MeDeploy offers an infrastructure that allows film distributors to build online ecosystems to distribute and sell films. The system is based on Amazon's EC2 (Elastic Compute Cloud) and is managed with RightScale tools.
"If anything, [moving away from EC2] would be easier than [exiting] an on-premises system," Taylor 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 Inc., which uses a proprietary programming language and its own 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," Staten explains. "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 suggests that buyers do in-depth research and ask the vendor to provide, under a nondisclosure agreement, information such as its cash position. He also recommends talking to the venture capitalists backing the company about their commitment to it. In addition, Staten says, ask references whether they're just dipping their toes in the water with the 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 they cease operations. Bonvanie has found that many cloud vendors are more amenable to this than most traditional vendors are.
It's also essential to set policies early on regarding 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.
So if you want to use five different cloud vendors, for instance, you need to be sure beforehand that you can customize all five platforms.
Creating these types of policies is not something many companies are doing yet, "because use of the cloud right now is a bit like the Wild West," Staten says.
Over time, standards will develop, most likely driven by customer demand, he says. This won't happen without tension, because customer demand will be offset by the advantages that vendors see in lock-in. For that reason, users need to be adamant about which standards they desire and where they're most important. One crucial area is in using open Web services in application-to-application communication, Staten points out.
Gartner Inc. analyst Richard Ni contends that IT leaders can encourage standards development by ensuring that their teams consider a wide range of vendors and technologies beyond the obvious market leaders. "We will encourage lock-in if we close our eyes to other vendors in the industry," he says. "The CIO has a role to play in ensuring several vendors are involved in the assessment, selection and due-diligence process."