Its one thing to have a cloud API, but it’s even better to have a library. Programming libraries provide proven abstractions where global variables can be set and reused at will and systematically smooth over the transition from an API/web-service to a programming language. They can save you a lot of time and effort–but they also take time, effort and upkeep to maintain as you can see from the dis-repair of the linked VMware VIX library.

One of the most prominent cloud scripting language libraries is Boto, a Python library for controlling AWS. It’s just the kind of developer and community driven asset I’d look for if I was making an investment in a cloud computing provider. You won’t see the progress of cloud programming libraries on the front page of the New York times, instead they are a volatile, grassroots, leading indicator of computing change (front and center to the Cloud Collision.)

Sooner than later they may shape up to an economic war-zone all-ah Java-vs-Microsoft of the last decade. Think the Azure libraries will be AWS compliant? Think again. Can you use Boto to manage the Rackspace cloud? As of right now…nope.

Boto users have begun to build out a series of scripts and programs to automate their computing tasks like this simple use case from their wiki:

I do batch processing on EC2. I use boto to fire up 20 or 30 instances, check that they started properly, transfer some files to them, and start a script…when done they use boto to save their results to S3. the batch-controller script waits til those instances have gotten fairly started, and then fires up more… i don’t do them all at once because S3 can’t keep up with loading data to them.

This is one of the simpler use cases, and very early days in the library’s evolution and advancement. But imagine you now want to sell your compute cloud to this workload. Guess what, the user has to recode. At this point it could probably be recoded in a quick session–as I said its early days. But now imagine it’s a year later and there are 300 Boto scripts running across the user’s enterprise, tied tightly into the application itself for automatic overflow to AWS. Sounds pretty sticky to me.

A battle to watch
On July 13th Rackspace released a beta implementation of their Cloud API. Because certain features of their cloud are not compatible with AWS (let alone authentication tokens) they will need to build a community of developers, libraries and tools for the Rackspace cloud. The cloud collision has indeed created interesting times! Here we have two operationally focused companies in Rackspace and Amazon who now must also compete for a community of software developers to succeed. It’s testament to how utterly central computing has become to mainstream society–the battle is no longer based purely on software architecture–highly efficient, massively scaled computing systems are also table stakes to compete for this new batch of software development.

I caught up yesterday with Rackspace’s Erik Carlin, Senior Architect for their cloud products  about libraries.

“There is tons of pent up demand from our customers for cloud server APIs,” he offered early in the discussion.

It’s clear Rackspace has community built  libraries for their API at the top of their agenda. They are going to be making investments to kick-start the community around their API. As has been well covered in the press they are positioning themselves as the more open-sourced, transparent, and community driven API. If you are a Rackspace investor watch their community growth around their API–look for value-ad libraries and frameworks built on top of their specification.

Network OS
Isn’t it the operating systems job to supply resources to programmatic calls? Its interesting to watch this new generation of ‘Internet programming’ emerging where script languages act as a traffic controller for both data and resources.

@wattersjames