Sign in / up

back to article 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 …

COMMENTS

House rules Send corrections
This topic is closed for new posts.
  1. Anonymous Coward
    Anonymous Coward

    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.

    0 0
  2. Nick B (Zeus)
    Go

    @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

    0 0
  3. Graham Bartlett
    Badgers

    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?!"

    0 0
This topic is closed for new posts.

Other stories you might like