Multi-cloud, what are the options? Part 1- Low level abstraction libraries

Multi-cloud has been around for a while. Apache Libcloud, one of the more popular low-level abstraction libraries was started in 2009.

Up to last year multi-cloud has been quite an unpopular topic. When I bring it up I get a lot of grumbles and frowns. People will have invested in a particular platform, coupled themselves to that platform and argue that multi-cloud is too hard, or that there is really no value and all you end up with is the “lowest common denominator” of features. Up to the past 2 years, I would agree that “too hard” is a more realistic description of the technology, but as I’ve previously written about, application portability is becoming a LOT easier. Docker has introduced this idea of packaging application deployment and runtime into a neat bundle, object storage is gaining popularity and direct-access storage requirements for applications like Windows Clusters have died a slow but overdue death.

I think the lowest common denominator argument is mostly moot when the idea is to be able to abstract the vendors away and depending on specific capabilities is just the same as coupling to the APIs themselves. Services like object storage, DNS, CDNs, Backups, are much of a muchness and there shouldn’t be any reason why deploying to 5 clouds should be the same experience and model.

SO you want to try running your application across many clouds? Just because your application may have Docker, you still need servers or infrastructure deployed somewhere, you still need storage, DNS, load balancers.

Low-Level Abstraction Libraries

Choosing a low-level abstraction library really comes down to target language, unless you’re using C#.Net, in which case you’re screwed. If you don’t have a requirement on language, you should consider which as-a-service components you want to abstract, because the libraries don’t offer a complete suite there.

The challenge that all of these libraries are trying to overcome is how do you provide a single interface to a set of APIs which are distinct. DNS is easy because it is a mature and standardised protocol, but compute is particularly tricky and each library has taken a different approach at tackling the problem with mixed success. Before you write-off the low level libraries because you can’t get all the switches and toggles for provisioning a VM that you might need, still consider the value in using them for DNS, Load Balancer or CDN/Object storage automation.

Apache Libcloud (Python) https://libcloud.apache.org/

I’m a little bias because I work a lot on Libcloud and really believe in what the project is aiming to achieve. It has excellent vendor coverage with over 50 clouds supported, plenty of community support and examples and some notable projects and companies using it in production.

You can hear me on FLOSS weekly episode 373 and on Podcast.__init__ Episode 55 talking about Libcloud, Python and why vendor API lockin is a terrible idea.

Pros

  • Good documentation
  • Good vendor API coverage and as-a-service coverage

Cons

  • The server deployment abstraction technique is really a challenge, for multi-cloud server deployment I would consider a mix-in of Hashicorp Terraform (which I will come to later).

Apache jClouds (Java) https://jclouds.apache.org/

A mature project with a well-tested abstraction layer covering all of the major cloud prodivers, jClouds has kept momentum by being the library in use by some commercial cloud management portals (CMP)s like Abiquo. Because jClouds is written in a strongly-typed language, the contracts are very concrete, a lot of work has been done to normalise the data between providers and think about how server provisioning and automation can be interfaced.

Pros

  • Very clean API

Cons

  • Missing some of the network-centric services like DNS and CDN, recommend you complement with another library where required.

Fog (Ruby)

Fog is library written in Ruby, it plays to Ruby’s strengths as a dynamic language by creating an easy mechanism to communicate with multiple clouds. What is important to note is that Ruby does not abstract the APIs or the systems, it provides a simple way of calling them, like a combined client library. You will still find yourself coupling to the APIs themselves using Fog, but it will save you a lot of time and a lot of dependencies.

Pros

  • Fantastic vendor coverage

Cons

  • Code quality is not comparable to some of the other libraries, drivers are missing tests
  • The models returned by the drivers are not normalised.

Libretto (Go) https://github.com/apcera/libretto

A new entry, Libretto was written by the engineers at Apcera purely to help them stand up VMs across multiple clouds in Go. I’m not too familiar with it, only that it supports AWS, Azure, GCE and Digital Ocean and it only supports VM deployments today. So if you are using Go, you should check it out.

PkgCloud (Javascript) https://github.com/pkgcloud/pkgcloud

PkgCloud uses some of the same concepts as Libcloud, like portable nomenclature for servers, images, flavours/sizes and has a similar API.

Pros

  • Very strong Database-abstraction API

Cons

  • The network services (DNS, Load Balancers, CDN) only support OpenStack/Rackspace APIs, which will prove a challenge for anyone trying to deploy the full stack
  • Missing Google Compute

Cloud Platform Coverage

The rest

I’ve seen dozens of other libraries that can be used to deploy a VM to Amazon, Azure and OpenStack in various languages. I’ve picked out those which go beyond this most obvious and simple to overcome challenge. I find it unlikely that your application consists of only a single VM and no DNS, so I haven’t included them for impracticality reasons.

Remaining challenges

These tools are very useful for auditing and tracking of assets across multiple clouds. None of the tools I’ve listed provide a single API for billing data, there are services out there for this like RightScale and Cloudyn, which amalgamate the bills into a consolidated format.

The biggest challenge they all face is VM deployment, I really blame VMware for this! They didn’t come out with a strong standard when they had the opportunity and lost in the long term, now all the vendors have mostly abandoned OVF (other than importing and converting to their own format) each of these libraries have to do a lot of juggling to figure out how to deploy a VM. It should be easy, but if you follow the constant changes to the Google Compute VM feature list, it’s mind boggling how many 1000’s of options there can be for running a simple VM.

Azure is a challenge for many of these projects because of the transitions to the Azure-Resource-Manager API (ARM), the lack of documentation around the ARM models and the complexity of it. Azure users may find a less-than-ideal experience on many of these libraries. Blame Microsoft, please. In writing.

Part 2 — Infrastructure-as-Code/Declaritive tooling is in the works. I will post soon.

Like what you read? Give Anthony Shaw a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.