Escaping From Locked-In Clouds

The first real controversy at the Structure08 cloud computing conference erupted during a panel called "Working the Cloud: NetGen Infrastructure for New Enterpreneurs." Not surprisingly, it involved Google.Christophe Bisciglia, a senior software engineer at Google and one of the search company's leading spokespersons on cloud computing, was forced by several other panelists to defend the openness of BigTable, Google's internal database system, which has been released as a hosted storage service for enterprises using AppEngine. The question being debated was whether BigTable, or other cloud-based storage and application systems, will require users to be "locked in," or tied to a particular infrastructure -- a proprietary cloud, to coin an oxymoron.

"People are creating portable applications for App Engine," asserted Bisciglia. "There's nothing about the model to prevent App Engine from running on a local server or any other cloud."

The other panelists didn't quite buy it.

"If you're using BigTable, to get the benefit of scale, you can't leave," countered Jason Hoffman, the founder and CTO of on-demand application provider Joyent. "The truth is, until you open-source BigTable, it is lock-in."

There are two sides to this debate, naturally, but it gets at one of the looming issues surrounding the advent of on-demand, pay-as-you-go cloud computing: if you choose to run your IT apps and services on an outside providers' infrastructure -- whether it's IBM's Blue Cloud, Google's App Engine, or Amazon's EC2 -- will you be tied to that providers' protocols, programming language, and APIs?

This dilemma explodes the oft-used analogy to the electrical power grid (cited by Nicholas Carr, author of the recent book on cloud computing, The Big Switch (W.W. Norton; 2008), in his videotaped opening remarks today): you can't just plug into a server cloud via an outlet in the wall, because no standards yet exist for Web-based IT infrastructure. If you choose to use EC2, so that you can scale infinitely and pay only for the computing and storage power you actually use, you are in some ways stuck because Amazon's APIs work differently than others. Moving to another cloud creates issues of interoperability and access because most have proprietary APIs.

That's not likely to change, said Geva Perry, CMO of GigaSpaces Technologies, because the various large-scale clouds are unlikely to merge into a single universal cloud or even a few.

"Will we end up with five clouds in the world?" Perry asked. "The reason that's not going to be the case is that there's a strong argument for specialized clouds." A health care infrastructure would be compliant with HIPA regulations, while other vertical specialized clouds would conform to other specific requirements. "There's room for both open and specialized clouds."

A related factor is geography. Despite the power of high-speed fiber connections, latency will continue to be an issue for real-time computing applications, according to Joe Weinman, VP of strategic solutions for AT&T.

"If you're looking to develop a global audience, the result is that you're subject to what I call 'the unfortunate economics of latency'," Weinman said. "To the extent you've centralized on a small number of nodes, there's an inherent difficulty in reaching end users."

The issue of geographical distribution, in turn, raises the thorny question of where the data legally resides -- an issue examined by Carr in a post today on his RoughType blog.

None of this is insurmountable, but it's worth considering that the remarkable promise of cloud computing, like any new technology platform, still faces significant hurdles between the present theory and the eventual reality. The lock-in question is just one of those.