When it comes to the cloud, concerns about issues like security and reliability supposedly are improving. But there’s one that hasn’t gone away: concern over lock-in. At our recent Bunker Session event on cloud computing and open source, lock-in was a topic of hot debate. The upshot? Although there are projects, organizations and even vendors trying to solve the problem, we’re a long way from the Promised Land of true cloud interoperability.

Where Lock-in Occurs

For internal cloud deployments, lock-in concerns generally mirror those found in data centers since the beginning of time. If you’re using proprietary software – database, application platform, whatever – the chances are that your application will be written to that specific software. Assuming your cloud is virtualized, your choice of vendors will affect what types of VMs your management platform works with. Problems also exist in the hardware layer, primarily in the form of vertical integration among particular vendors’ various server, networking, storage and systems management products. It’s nothing new, really – decisions must be made between proprietary and open source, or between closed and open. However, as I wrote recently, numerous open-source and standards-based solutions are emerging to address cloud-specific concerns.

The real cloud-computing lock-in problem is in the public cloud, where it isn’t necessarily about vendors as much as it is about providers. Because pretty much every cloud provider uses its own API and its own unique database – and most PaaS offerings are locked down in terms of languages supported and runtime – applications and data don’t always move easily among cloud providers’ infrastructures. Without calling in the services of a third party or an open-API project (more on those later), users trying to port an application and its associated data from one cloud to another are in for a rewriting project, at the very least.

A less-publicized cause of cloud lock-in, against which Yahoo’s Tom Hughes-Croucher and Carlos Bueno are leading the fight, is the network. Even if the data formats are compatible, it takes a lot of time and can cost a lot of money to send data between clouds. This is because inter-cloud data must traverse the public Internet and, thus, receives the same treatment as all other data. The cost comes from bandwidth charges, for which most cloud providers charge users both coming in and going out.

Tools to Overcome Public-Cloud Lock-In (and How They’re Working)

Cloud brokers

Probably the most common – and easiest – approach to overcoming cloud-provider lock-in is the use of cloud brokers. RightScale is the largest and most established cloud broker, having launched more than 1 million cloud servers for its clients thus far. Users manage applications using RightScale’s open and user-friendly platform, which performs the legwork of running applications on the right cloud(s), automatic scaling, etc.  Other cloud brokers in the market include Kaavo, EnStratus and CloudSwitch, each of which provides its own unique features and its own degree of abstraction from the underlying cloud platforms.

There are, however, drawbacks to using cloud brokers. The biggest, probably, is that they add additional costs. RightScale, for example starts at $500 per month (plus a largish one-time setup fee) per account, and support and other services add even more. Another problem (if you can call it that) is that cloud brokers don’t solve the problem of cloud interoperability. They certainly ensure portability between supported cloud providers, but they cannot overcome the fact that cloud providers have not architected their platforms to work with one another in a best-of-breed manner.

Open APIs

There has been a proliferation of open API projects over the past year, from a variety of different creators. Some examples include Red Hat’s Deltacloud, Apache’s libcloud and Zend Technologies’ Simple Cloud API. Like cloud brokers’ offerings, open APIs let users write applications to their needs and the API translates it to work with various cloud offerings. Deltacloud even offers a web user interface to simplify the process of managing and migrating instances between clouds. Like cloud brokers, however, open APIs don’t overcome cloud computing’s inherent lack of interoperability, and open API projects require users to learn a new programming method without customer support or a corporate throat to choke.

An “interesting” approach to openness comes from the cloud providers themselves, which have taken to open-sourcing their APIs in the hopes of positioning themselves as champions of cloud openness. Of course, this type of altruism – whether from Rackspace, GoGrid, or VMware – is largely symbolic and, to a degree, is self-serving. Ego, it seems, makes it unlikely that independent cloud providers will adopt another’s API when they could write a “better” one on their own. In the case of VMware, its open vCloud API serves the purpose of bringing more service providers into the vCloud Express fold and, some would argue, actually locking users into VMware’s vision of cloud computing.

Open Source

The connection between open source and cloud computing was the focus of our recent Bunker event. A major concern that arose during the discussion is that although most cloud-computing platforms are built using open-source tools, the end-products are decidedly not open source. So, aside from open public-cloud APIs, open source in the cloud, as a means of avoiding lock-in (and not just running open-source OS instances), is relegated largely to the internal-cloud sphere.

Standards

There are various cloud standards project underway, but the word is that they’re not advancing too quickly. Not that it’s necessarily a bad thing: some have argued that standards at this early point might impede progress, and there is the fear of disparate bodies releasing different standards on the same aspect, thus creating more problems than they solve. The bottom line on cloud standards, especially outside of storage, is that we’re a long way from maturity.

Market Pressure

Market pressure is forcing interoperability among hypervisor vendors within the data center, and conventional wisdom suggests it could force some degree of interoperability among cloud providers, too. Money talks, and if customers make it clear that they won’t commit fully to cloud computing until they can create their own best-of-breed application environments using various services from various clouds, we might actually see some action. Maybe providers just need to relax their grips enough to let third parties, like RightScale, step in and fill the void.

The Outlook

When it comes to public clouds, third-party management solutions and open APIs have made lock-in far less of an issue than it was a few years ago. However, even if applications can be ported from one cloud to another, lock-in can’t really be solved until clouds actually work together to some degree. Otherwise, users are, for all intents and purposes, still locked into their cloud provider of choice for each individual application. Easing inter-cloud data transfer or agreeing on a simple standard for migrating instances among providers would be a fine start.  Clouds don’t need to be open source, but they do need to be open.