An API for cloud infrastructure services


If you are a cloud provider or consumer, specifically in the Infrastructure as a Service (IaaS) landscape, it’s hard not to be excited by the work going on in the Open Cloud Computing Interface Working Group. Owing to the growing number of IaaS providers and increasing adoption of the relatively new paradigm by consumers, this group was formed with a goal of bringing about standards to manage these cloud-based infrastructures. The following goal statement on the group’s home page sums up their intentions quite nicely:

“… deliver an API specification for remote management of cloud computing infrastructure, allowing for the development of interoperable tools for common tasks including deployment, autonomic scaling and monitoring

The working group has an early draft of the specification, which while still in its infancy, gives a good peek into the direction they are heading. The current draft consists of four distinct parts:

1)  The OCCI Core and Models: Defines the resource model for the specification. This includes the resources and resource collections, and the HTTP verbs used to interact with them.

2) The OCCI Infrastructure Models: Defines the three “kinds” of resources (compute, network, storage) associated with IaaS platforms. This document also defines actions with these resources and an extension model to enable other capabilities.

3) OCCI XHTML5 rendering: Defines XHTML5 rendering of the resources defined by the specification.

4) OCCI HTTP Header rendering: Defines the use of HTTP headers by implementers of the specification.

Personally, I’m not surprised to see three of the four above included as part of the specification. What I am surprised to see, and happily so I might add, is the inclusion of the XHTML5 rendering piece in the specification. This seems to set forth a common XHTML5 representation for the resources and resource collections included in the specification. Standardizing on a common representation format will make the process of client development much simpler, and it should enable aggregation at the GUI level (i.e. a single GUI for multiple IaaS providers).

Another thing I’m happily surprised about is what we don’t see in the current specification documents. I didn’t spot the presence of a single strange, head-scratching implementation detail making it into the draft. You may be wondering why I would be surprised about that. After all, specifications are supposed to be free of any kind of implementation detail, right? Well what they are supposed to be and what they often turn out to be can be two different animals. This becomes even more of an issue when, like with Amazon EC2, there is an existing solution in the specification’s domain space that has significant adoption and traction. In my opinion the specification started off on a solid footing by dodging this potential pothole.

While the eventual completion, certification, and wide-spread industry implementation of this specification is a ways off, it is a promising beginning. Keep an eye on the work of this group, and if you are so inclined take advantage of the open process and join the working group.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: