
Libcloud: One Interface To Rule Them All - shrikar
http://libcloud.apache.org/
======
ikusalic
I hope libcloud gets some traction.

The problem is, currently it's not really mature enough. The whole idea is to
use one interface so you don't end up with writing special cases for different
IaaS. The problem is that it simply isn't fully-featured and that the
interface for different platform differs even when it's not really necessary.

I've been using it to interact with AWS and OpenStack, but still end up with
lots of special cases and even falling back to boto for some AWS features
(e.g. CloudWatch).

I really hope they fix the interface issues and cover more features of
specific platforms in future.

------
1qaz2wsx3edc
In the ruby ecosystem Fog has existed for a long time which offers a similar
service: [http://fog.io/](http://fog.io/)

Edit: I should also say it's neat to see an apache supported project in this
space, more tooling around these services are very useful.

~~~
khc
jcloud recently became part of apache:
[https://jclouds.apache.org/](https://jclouds.apache.org/)

~~~
moondowner
Link to GitHub [https://github.com/jclouds](https://github.com/jclouds)

jclouds is good for Java and Clojure projects.

------
geertj
Each cloud has its own semantics. Unless you want to unify the semantics,
you'll either end up with lowest-common denominator APIs, or cloud specific
methods.

What is needed is a standard for discoverable RESTful interfaces. With that,
there could be a single client library for each platform/programming language
to access any compliant API.

The metaphor is here that i don't need a different browser to connect to
Citibank's and Bank of America's online banking services. A single browser
works just fine. This is the deeper meaning of RESTful, something which is
overlooked by many people.

~~~
boronine
I've been working on something very similar to what you are describing:
[http://www.cosmic-api.com](http://www.cosmic-api.com) I would really
appreciate some feedback :)

~~~
pfraze
Looks nice. To really evaluate it, I need to see what the HTTP endpoints and
traffic look like. My concern is what experience a non-cosmic client would
have.

------
foxhop
I'm using salt-cloud which uses apache-libcloud. I've blogged a few times
about it here -

This post shows how to stand up fleet of servers with Digital Ocean and salt-
cloud:

[http://russell.ballestrini.net/create-your-own-fleet-of-
serv...](http://russell.ballestrini.net/create-your-own-fleet-of-servers-with-
digital-ocean-and-salt-cloud/)

This post shows how I quickly setup a Sensu monitoring test environment:

[http://russell.ballestrini.net/sensu-
salt/](http://russell.ballestrini.net/sensu-salt/)

------
pothibo
Not sure I'm a fan of wrapping libraries like that one. It tried to abstract
things from you, but on the the other hand, you need to know the
implementation details of each provider to understand the behavior of the
library.

Maybe I misunderstood what it does?

~~~
kordless
Most wrappers exist to provide a fast and easy way to execute common methods.
They likely make it trivial for most people to implement something quickly.
Those who need functionality beyond what they provide probably don't care
about it being easy to implement and probably won't use it. It's a choice.

------
retrack
With this new website, the libcloud community has done a great job of better
documenting. The list of supported providers has also increased. we are glad
to be part of the adventure with exoscale:
[https://libcloud.apache.org/blog/2014/01/27/libcloud-0-14-an...](https://libcloud.apache.org/blog/2014/01/27/libcloud-0-14-and-
the-new-exoscale-driver.html)

------
contingencies
I agree that the result of these APIs can be a dumbing down of your cloud
infrastructure. IMHO, the major challenges inherent in having multiple cloud
providers with differing APIs is absolutely _not_ writing code to use them,
rather: \- infrastructure management \- workflow process security \-
credential security \- offline workflow (local emulation) support \- cost
comparisons \- performance observation / guarantees \- SLA \- recognition of
disparate legal jurisdictions where required \- managing nontrivial inter-
service build and live dependencies \- complex or non-standard network
topology support (ie. not "single default route to the internet" or "single
default route to the internet, secondary route to cloud provider specific
renamed VLAN concept") \- embedding real time failover

Keeping all of the above out of the way of regular programmers who just want
to write cloud provider neutral services is the real challenge. None of these
libcloud/libvirt type solutions ever target the above, which mostly border on
operations concerns.

I am now working on the second functional prototype of a system that I believe
goes a long way toward resolving these issues by taking a broader, more
operations-centric perspective on the evolving norm of multi-provider cloud
infrastructure within companies that may include remote developers, require
offline development support, and still need to maintain higher standards of
trust and security.

Those curious can browse the presently rather obtuse documentation at
[http://stani.sh/walter/cims/](http://stani.sh/walter/cims/) .. I am
considering asking my company to allow me to open source it.

Right now we have storage providers for LVM and ZFS, and support for an
internal, high availability corosync/pacemaker cluster + LXC based cloud
provider in addition to a range of popular commercial ones. Very interested in
feedback and/or experienced/motivated help.

------
nbevans
No Azure support? Really? But has support for various minnow providers...

~~~
DamnYuppie
Yeah....I mean Apache and MS have always been so tight, hard to imagine them
getting left out ;)

~~~
gtirloni
Microsoft is a platinum sponsor of the Apache foundation nowadays:

[http://www.apache.org/foundation/thanks.html](http://www.apache.org/foundation/thanks.html)

[http://www.apache.org/foundation/sponsorship.html](http://www.apache.org/foundation/sponsorship.html)

------
computer
> "Latest stable version: 0.13.2"

Does that mean that they suggest I can use this in production (since it's
"stable") or that I can't, since it's not at version 1 yet?

~~~
briancurtin
We just released 0.14, and the next will move to 1.0. The general feeling is
that it _is_ stable, and people really like seeing "1.0".

------
dmourati
Honestly the one interface should be the AWS API. Eucalyptus has already
embraced it and set the tone. OpenStack is partially there but political
battles in the community have forced a stalemate.

If you standardize on the lowest common denominator, you lose many of the key
features of AWS such as VPC and autoscaling.

~~~
kordless
The AWS API is an INTERFACE to a proprietary system which runs closed source
code. The code that runs the API endpoints is also closed source. Whether or
not the SDKs for the AWS API are open or not is irrelevant to this discussion
(not that you said something to the contrary, but I'm covering my bases here).

Eucalyptus has no more or less 'embraced' the AWS API methods than OpenStack
has - save for a bare few methods that have different connotations in
OpenStack land than they do with Euca:
[https://wiki.openstack.org/wiki/Nova/APIFeatureComparison](https://wiki.openstack.org/wiki/Nova/APIFeatureComparison).

The 'political battles' you are citing in OpenStack are actually a bunch of
cage rattlers who are promoting their own interests in their respective
service offerings. Going into a company that uses AWS for infrastructure and
trying to pitch them on OpenStack is a long, drawn out process. Selling new
technology is hard.

The lowest common denominator benefit that OpenStack provides is an open and
transparent code base that can be modified and utilized by anyone. It's that
openness that allows the few people using features like VPC and autoscaling to
write some simple code to do deployments on whatever they like. Honestly, it's
a handful of lines of code at the most for any given method. Saying you 'lose'
feature functionality is simply a rationalization for attacking the OpenStack
movement.

~~~
jsmthrowaway
Rackspace pitched OpenStack _hard_ to competitors when they released it. I
mean _hard._ They were practically begging various folks to give them a moment
to discuss switching entire hosting services over to OpenStack. The strategic
play was, and remains, fairly obvious: if you remove feature differentiation
the market competes on other differentiators (Rackspace wants to compete on
support, most likely). Given that historical context of OpenStack's origin and
not-so-subtle strategy, it's interesting to see such a dismissal of hosters
that still want to compete on features.

Think about it. If you launch a hosting shop today and adopt OpenStack, you
will be able to offer a similar feature set to Rackspace right off the bat.
You then have to begin work on how to differentiate yourself feature-wise,
while meanwhile not really competing with Rackspace because it's the same
offering. OpenStack tells us that Rackspace wants all hosters to look largely
equivalent technically.

I'm pretty sure what's where the project came from. Now, however, it appears
to be evolving into a community effort to compete with Amazon, which is smart
on Rackspace's part: by making a community effort, Rackspace (and everybody
who runs OpenStack) get to capitalize on the work of the community to build an
Amazon-like system, since such a system would require a significant investment
on Rackspace's part and they likely don't have the people to do it. The
danger, however, is that we'll end up with a hosting industry with dozens of
AWS clones.

Regardless, in the broad, virtualization was our crutch until Linux containers
caught up to what zone/jail admins have known for decades: there are far more
efficient ways to share a machine than virtualizing an entire OS. The smart
minds are focusing on containers now. I know OpenStack just implemented Docker
support in Nova, but I don't think OpenStack models container computing well.

------
stackcollision
Did we learn nothing from LOTR?

------
bachback
cool. how does this relate to packer & vagrant? this is basically the trend to
an abstract machine interface. so you can boot an image at several place and
you want notice. this will matter in terms of price and consumer power.

------
tbarbugli
sounds like a really ambitious project to me, I cant do anything else then
wish the dev team good luck! (and use boto meanwhile the product matures :))

------
bachback
repo: [https://github.com/apache/libcloud](https://github.com/apache/libcloud)

------
andyzweb
and in the darkness ...

