We launched our RESTful Cloud Servers API last week and the feedback thus far has been fantastic. When we were first looking to build the API, we surveyed the cloud standards world to see if there was anything existing we could embrace. After all, why have another cloud interface if you can avoid it? We believe in a world of open clouds where customers can migrate, federate, burst, etc. and not be concerned with lock-in. Common APIs are part of that battle, but unfortunately, nothing suitable existed (although OCCI looked interesting). So, we built our own interface embracing easy to use web service standards like REST, , XML, JSON, etc. We spent a lot of time modeling a compute cloud in a RESTful manner and adjusting based on feedback from our developer and partner communities. The responses we got back helped us course correct as part of the design process and that open approach resulted in an API that is powerful, yet easy to use and understand (there is of course plenty of room for improvement). We’ve heard that message over and over during this past week.
Still, we had to create a proprietary interface which in some ways, makes the cloud world more divergent. So, in order to share what we’ve designed and to foster a more open cloud, we announced yesterday at OSCON that our Cloud Servers AND Cloud Files API specifications are now open sourced under the Creative Commons 3.0 Attribution license. This means anybody building private clouds, other public clouds, developing standards, etc. is free to take the specification design work we’ve done and copy it, modify it, or reuse it any way without fear of legal action. We don’t know if that will happen, but we at least wanted to make it possible.
That deals with openness on the cloud service side – now let’s talk about the client side. When Cloud Files was built, in addition to a RESTful interface, Rackspace also built Java, Python, Ruby, PHP, and C# language bindings. One of our overarching design goals at the Rackspace Cloud is to make the cloud easy to use, and we believe a canonical set of bindings, consistent across languages, helps to achieve that. In an effort to open these to the community, we have now made all Cloud Files bindings, open sourced under the MIT license, available on github at http://github.com/rackspace. We invite people to pull down a copy and begin making contributions. We’d love to see the community take ownership of them and eventually have external committers as well. For more information on how to get involved, hop on the Cloud Files IRC channel at irc.freenode.net #cloudfiles.
With Cloud Servers, we are taking a different approach with language bindings. We want to engage our developer community and enable them to build and own the bindings, but do it in a manner that still provides cross-language consistency. To that end, we have created a Cloud Servers technical specification that serves as a blueprint for how to build bindings. This is also available on github at http://github.com/rackspace/docs-specs-cloud-servers-language-binding/tree/master. We will soon release a reference implementation in Python, which along with the tech spec, will provide good guidance on building in other languages. We are just now getting this out and already, after one week of the RESTful API being available, we are aware of Twisted Python, Ruby, Java, and Perl bindings done or on the way. Now that’s a great response from our developer community! Thank you. Our job is to work with you to help bring alignment to the tech spec and minimize competing/redundant bindings. If you are developing Cloud Servers bindings or are interested in being involved, you can get more info on the Cloud Server IRC channel at irc.freenode.net #cloudservers.
We’re not sure where things will go, but we are committed to openness, being involved in standardization discussions, and taking a proactive role in our developer community to foster an open cloud.