afaics this only reinforces the use case for just using the underlying native client lib. istm the only portable cloud usage for libcloud is its original use case, read only access for cloudkick monitoring. In some cases its the only decent py lang binding to a given cloud provider and its been great to watch libcloud grow over the years as an apache project that providers target. But the reality check is as an app developer you can get over 90% public cloud marketshare with 3 cloud providers (ec2, openstack, vmwware), and maybe toss in a virt provider masquerading as cloud (ala linode, dotcloud) to get to 95. Given that your extending a from scratch client in libcloud and your abstracting it in an app code base, for most of those you could just go with a native cloud provider and get more functionality. ie. take saltstack's saltcloud as an example of a heavy user of libcloud, they had to create a utility library, and still ended up with 1k lines per cloud of specific code just for something as simple as launching an instance (no volume management, no security group management) just launching an instance. that line count would have dropped and they would have access to more features if they would have just used native cloud libs, if they were willing to grow the per cloud dep. anyways, thats the tradeoff of an lcd library afaics.