tomazmuraus

(disclaimer: I'm one of the Libcloud developers)

I want to add some context to this.

Our current abstraction provides a relatively simple API which is guaranteed to work across multiple providers.

If you want to access provider specific functionality we offer so called extension methods and arguments. This is similar to how jclouds and other cross-provider libraries handle that as well.

We support over 30 providers and for the more popular ones this means you can usually access most of the native cloud functionality through the base API + extension methods.

Doing that will obviously make it harder and more work to switch between different providers so we always put up a disclaimer and make sure our users are aware of that.

We are trying to standardize as many APIs as possible and promote extension methods to the to top level API (proposals and patches are always very welcome and appreciated!), but sadly in a lot of cases this is not possible. Usually this is because the provider APIs are too different and the glue code needed to make it work would be to complex.

In the end it's a trade-off, pretty much like everything else in life and a lot of other things in CS (CAP anyone?).

If you want good portability and easily switch between providers you will stick to the base API. If you don't care so much about the portability you will also use the extension API.

Side note: Even though official provider client libraries exists, a lot of people still tend to use Libcloud with extension methods.

Usually the reason is that we support a variety of Python versions and we have a stricter testing policy which tends to result in less buggy code.

It shows how easy it easy to write your own function because all you need to do to send an email is perform a single HTTP request.

Just FYI, apache mod_proxy_balancer also supports HTTP 1.1 and you can configure it during run-time if you have mod_status enabled.