Open source API dreams of The Meta Cloud
Calling the cloud of clouds
The Meta Cloud is one step closer to meta-reality.
Last week, at OSCON, a San Jose startup known as Cloudkick unveiled an open source project that hopes to provide a single programming interface for a host of so-called infrastructure clouds, including Amazon EC2, Rackspace Cloud Servers, Slicehost, and GoGrid. Dubbed libcloud, the project reaches for a world where developers can build an app that's easily shuttled from one cloud to another.
You might call it The Meta Cloud API.
Cloudkick already offers its own RightScale-like management tool for overseeing the use of Amazon EC2-like infrastructure clouds - i.e. web services that provide on-demand access to scalable compute resources. And with this management tool, you can juggle multiple clouds from the same web dashboard. But with libcloud, the company has expanded on the cloud-of-clouds idea by providing a common API for such services.
"libcloud is useful for anyone who wants to write some sort of software that works between clouds," Cloudkick's Alex Polvi tells The Reg. "If you wanted to, say, develop tools that automatically move your loads to the cheapest provider, there could potentially be a libcloud implementation that does that."
Emphasis on potentially. At the moment, you can use a single API call to list server instances across Amazon EC2 and EC2 Europe, Rackspace Cloud Servers, Slicehost, VPS.net, and GoGrid. And another call lets you reboot servers across both EC2 and EC2 Europe. But that's the extent of it.
OSCON also saw Rackspace open source its own Cloud Servers APIs, with the hope fostering an industry standard for infrastructure clouds. But for the foreseeable future, as Amazon continues to resist such efforts, we're stuck with incompatible interfaces ripe for a client library along the lines of libcloud.
Written entirely in Python, the project is hosted here on Github. ®
Of course, this is going to be a nice fast system, using Python as the programming language and running over a zillion indirection layers...
That's the problem. CompSci says "ain't this a neat idea?" Real world says "physical time involved in processing and communication". Users say "jeez, this sucks - how can this be so slow?!"
The answer is not to use the built-in features, but use a product that can provide that functionality in multiple clouds. You can then replicate these "high level goals" in the same way, in multiple places. This negates the problems of "translating" the differences in semantics.
So to take load balancing as an example, deploy a software load balancer (it could be open source or a commercial offering like our ZXTM) within the vendor's cloud in just the same way you would a web server. You can then exactly (with a couple of tweeks in how it fits into the architecture) replicate this installation in multiple clouds.
not so interesting, actually
From our point of view, something like libcloud is not all that interesting, actually. The problem isn't having a pieces of code that know how to generate a "list servers" call and parse the response for several different clouds. The problem is being able to construct multi-server architectures and deployments that can make use of Amazon's load balancing service, IP address allocation scheme, and block storage service, and that can then be moved to RackSpace, which uses quite different ways of accomplishing the same high level goals. These are differences in semantics of the resources being allocated and used in the cloud, not just in the syntax of the API calls. *That's* the fun part from our experience at RightScale.