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 Inc. , 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.” “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,” he says.
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 Inc. 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.
“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.”
Then, there’s fear itself
Technicalities aside, lock-in is also an emotional issue, says Rene 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 any cloud system, but people are more concerned 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,” he says. “But the reality is that it’s like money: If it’s in a vault, it doesn’t matter whether 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 shake out 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 specific 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 business processes that fit into this architecture without having 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 says.
Staying out of the vault
Another way to approach the lock-in conundrum is to use Willis’s 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 with cloud software and platforms come nonstandard APIs, system calls and other proprietary technologies. (Lamia Youseff of the University of California at Santa Barbara offers an interesting look at the cloud computing landscape — download PDF .)
A case in point is Microsoft Corp.’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 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 tradeoff, 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 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.
So if you want to use five different cloud vendors, for instance, you need to be sure beforehand that you can apply those customizations to 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. However, Staten points out that security customization is yet another way to get locked into a particular vendor, because if you wanted to move to a different provider, you would need to unwind and then redo all that work.
Maturity takes time
Over time, standards will develop, Staten says, most likely driven by customer demand. This won’t happen without tension, he says, 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 says.
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 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.”
As the hype about cloud computing begins to settle down, the hope is that lock-in concerns will grow more rational and less emotional. That will be a welcome development to Bonvanie, who sees just as much risk with traditional computing systems. In fact, his use of NetSuite Inc.’s Web-based business software and IntAcct Corp.’s Web-based ERP software has convinced him that they have easier interfaces and procedures to retrieve and unload data than SAP AG does.
“What gets me nuts is that the same people who are concerned about lock-in in the cloud are not concerned about it behind the firewall or on-premise systems, where people normally run mixtures of three or four different breeds of Unix,” Willis agrees. “It’s much harder to move from AIX to Sun than to move from Amazon to FlexiScale,” he says.
Willis looks forward to the day when people stop asking whether the cloud causes lock-in. “It’s the wrong question,” he says. “The cloud is just the furniture.” Instead, Willis says, remove the word cloud altogether and ask, “Is there lock-in in the choices I’m considering?”
Mary Brandelis a Computerworld contributing writer in Newton, Mass. Contact her atmarybrandel@verizon.net .
