Open source API dreams of The Meta Cloud
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, …
This topic is closed for new posts.
Posted Tuesday 28th July 2009 05:22 GMT
Thorsten 1
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.
Posted Tuesday 28th July 2009 10:30 GMT
Nick B (Zeus)
@Thorsten...
#
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.
Nick
Posted Tuesday 28th July 2009 11:53 GMT
Graham Bartlett
Performance?
#
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?!"
This topic is closed for new posts.
Back to the article
