Cross Cloud APIs

Written by: Michael Neale
3 min read

So at CloudBees we use a variety of cloud APIs libraries (and have experience with many more) to do our thing (IaaS cloud APIs - that is !).

The promise of many of these (as opposed to using a vendors API directly) is cloud portability. Of course reality, as often happens... gets in the way.

I often hear it mentioned that if you just stick to these generic APIs - you will be free from cloud lock-in. Hearing this warms my heart with its innocence. This isn't to say the dream isn't possible, it certainly is, but it isn't quite so easy to achieve as that. Given it is possible, but challenging, then at the moment you have to still ask the question of how much you want this portability: it boils down to accepting a common denominator and avoiding value-added features - or doing a lot of work to reproduce them in different target cloud environments.

Nevertheless, here are a few great tools we use:

Jclouds is a java based API which provides abstractions for generic compute and storage services, and is embracing the common denominator as it emerges. What is notable about jclouds is how easy it makes to dive down into a low level API (eg, EC2) when you need to, but avoid binding it to it when you don't. It has an active community and works very well.

Fog is a handy Ruby gem - and very similar in aim and result to jclouds, but for Ruby. It is used by chef with great results - and provides easy access to specific cloud features when you want them.

So what is missing for the "grail" of IaaS cloud portability? Well it is still early days for what people consider is required by an IaaS cloud (is it just instance/server lifecycle management, does it involve volume handling, firewalls etc). But what we do know is the common denominator, this is probably best represented by the project (started by some folk in Red Hat). I have seen that work with public and private clouds (and written some stuff in it). It is a good example of the current common-denominator. This is useful for many workloads, but misses a good chunk of features that many IaaS clouds provide.

If we were to enumerate some of the more tasty features that are popular today - we could come up with a potential list of "cloud primitives" - features that we hope will one day be common enough to be exposed in a truly portable way:

  • Instance lifecycle (done like a dinner!)

  • Snapshotting and restoring of instances (also works well!)

  • Firewall management (varies quite a bit, definitely non standard)

  • Volume management (non standard, or missing from many established clouds)

  • Bulk data stores (blob store ) - getting more and more common!

  • Address management (ie., binding IPs, choosing IPs, naming etc - all non standard)

  • Availability services (entry points/load balancing and monitoring - non standard).

Now to say "non standard" implies (to some people) that is naughty and to be avoided. That is definitely NOT the case. These are fantastic tools by real innovators, and should be used. It would be terrible to prematurely settle on a standard for cloud primitives, a common denominator at this time.

Let's see how things evolve, it won't be boring.

-- Michael Neale, Elite Developer and Architect

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.