One of the main goals of the cloud, and in particular IaaS, is to automate the deployment of infrastructure resources, such as compute, storage and networking. Although this automation may be through the consoles of different providers, it should be flexible enough to meet the needs of each tenant, and an API is a must to achieve this.

In Abiquo we have a RESTful API that enables access to all resources and features of the platform, in order to allow cloud providers and cloud consumers to extend the platform to suit their needs. This API is quite simple (just like any other RESTful API) and complete, but it is not as user-friendly as it could be. Delegating to the end API users the responsibility of generating the requests, serialization and error handling makes it difficult to accomplish the main API objective: to provide an easy way to extend the platform.

For that reason, we decided to write an official API client in Java. We chose Java because it is the language in which Abiquo is written, and because it is high-level enough and there are many REST libraries to enable us to build the client quickly.

The jclouds way

jclouds-logoFirst we started writing our own Java API client, but we spent a long time just building a wrapper of our RESTful API. But we really wanted to provide a higher level of abstraction and a set of services that easily empowered the implementation of the most common use cases, so we decided to change the approach.

At the same time, we were adding Chef featuresto the platform, and we used the jclouds-chef project for that. So we started to take a deeper look at the jclouds code, we started to study the jclouds ecosystem, and we made some code contributions to the library that helped us develop our features.

Doing that made us realize that the library was very good and provided a set of abstractions that fitted our model pretty well, so we decided to rewrite our API client from scratch, the jclouds way.

Today I can say we made the right choice.

Not only does the library perform well, it also enabled us to focus on building the high-level services, and introduced a very nice way to test the API. The unit and expect tests, along with live tests, gave us the level of confidence we needed for our API.

Furthermore, it also gave us the ability to implement their ComputeService (making an Abiquo cloud compatible with other clouds supported by jclouds), and to maintain a provider-specific API exposing all features existing in the platform.

Pros and cons

From our experience in writing the Abiquo provider, I have encountered many advantages, but also a few things that in my opinion could be improved.

  • One of the key benefits of the library is that it is open source, and in addition to open source, it has a good community. The mailing list is very useful and almost every question gets an answer in the #jclouds IRC channel.
  • Also when you make code contributions, you get constructive feedback, teaching you about the internals of the library, so people can easily get involved in the project.
  • It has also given us vision, and made Abiquo more attractive to our customers and third parties thinking of starting integration projects with us.
  • One of the things to improve is the documentation. They are currently making an effort to improve it, and a brand new site will soon be released. But in my opinion, developer documentation (and javadoc, etc) should still be improved. There are many times when one has to go deep inside the library to find out how it is doing stuff.
  • The other thing that I consider could be improved, is the integration of third party developments inside the official jclouds release cycle. In the current model, there is one single git repository with all the code, and all the providers are inside that repository. This works well to keep all providers up to date, and in sync with the latest developments, but makes it harder for third-party developments to be merged. Also having few people maintaining all the providers may not scale someday. Splitting the providers into different repositories and having a system to build and release them together (using git submodules, for instance, or whatever) could provide more flexibility in this area and let them benefit from third party code.

One library to rule the cloud

Jclouds is becoming the de facto standard library to build portable cloud services in Java, and in our case it has been a great success, because having the Abiquo provider has given us more visibility and has attracted attention to our platform. The project is also experiencing good momentum, and its community keeps growing, so we expect very interesting stuff to be built on top of it soon. And of course, we’ll be there!

We’ll keep pushing the development of the Abiquo provider and I hope to have it incorporated in the jclouds release lifecycle soon, just like any other officially supported provider. Stay tuned!