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.
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.
Project Awesome is an HTTP proxy which means it's even a higher abstraction than a Ruby library :)
In any case, you should have a look at Libcloud (http://libcloud.apache.org/), jclouds (http://jclouds.org), deltacloud (http://deltacloud.apache.org/) and other libraries. Deltacloud exposes a similar functionality through an HTTP interface. We have recently also started working on "Libcloud REST" which will expose all the Libcloud functionality through an HTTP interface which means you will be able to talk to it through an arbitrary language which can speak HTTP.
This is a nice achievement but I think if you extracted the process orchestration part and made it use mocha for test layout, running of individual test files, and reporting (which it does a really good job at) it would be more useful.
We actually do have an install script. It is not the best one, but you should be good to go in a few simple steps:
1. downloading a tarball
2. unpacking it
3. running "scons install"
Scons (our built tool of choice) is an extra dependency, but this shouldn't be a problem since it's a prerequisite for Node.js itself (platform on which Cast is built).
I didn't try it, but probably pretty close to working. It does more than some people might want, but I didn't write it for the pedants in the crowd. ;-)
Service management part is also abstracted away pretty well, so it should be fairly easy to write a new backend for your favorite service manager (supervisor, upstart, etc.).
Don't get me wrong. I love runit. Simple and effective. Runs on all my deployments, which is a lot nicer than rc scripts for FreeBSD (which isn't really comparable anyway), Upstart for Ubuntu, this for this and that for that.
Consistency is nice.
Just never figured out how to get it to start on boot in FreeBSD (it's not just runsvdir_enable="YES").
Exactly, If I were using node and needed to calculate primes I'd probably write some C++ code to handle that part and run it as a server in a separate process that can be called asynchronously from node.
Hopefully you'd try another algorithm before you did that ;). Primality tests are one of the most highly understood and well documented areas of CS - trial division has been obsolete since, what, 1640?
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.