Cloud Zone is brought to you in partnership with:

Mitch Pronschinske is the Lead Research Analyst at DZone. Researching and compiling content for DZone's research guides is his primary job. He likes to make his own ringtones, watches cartoons/anime, enjoys card and board games, and plays the accordion. Mitch is a DZone Zone Leader and has posted 2576 posts at DZone. You can read more from them at their website. View Full User Profile

Red Hat Makes a Bid for Standard Cloud API

08.27.2010
| 8957 views |
  • submit to reddit
This week, Red Hat announced that it had submitted the Deltacloud API to the DMTF (Distributed Management Task Force), a body that oversees standards such as CDM (the Common Diagnostic Model), DASH (the Desktop and Mobile Architecture For System Hardware), and OVF (the Open Virtualization Format).  Red Hat believes that Deltacloud has the potential to become a standard for cloud interoperability if support builds for their open source API. 

Some vendors like Eucalyptus, have declared their support for Amazon's S3 API as the standard cloud API since Amazon has such a dominant position in cloud computing market share.  Red Hat argues that it's too early to declare S3's API as the standard, not to mention the fact that it's too vendor-specific.  Other organizations are also coming out in support of truly open source cloud interoperability technology, specifically the OpenStack project, which includes technology from Rackspace and NASA.  Rackspace has actually been pulling in some of the most talented developers because of the company's contributions and staunch support for open source technology.

The Deltacloud platform, in contrast to S3, is an Apache Incubator Project, which puts the APIs direction under the control of a vendor-neutral third party.  The incubator proposal states that Deltacloud's mission is: "to define a truly open-source cloud API, one for which there is a proper upstream, independent of any specific cloud provider."

So why do we need an open cloud interoperability API?  Red Hat recently discussed the issues:

"Let’s say you want to run an application container–which is to say a virtual machine (VM)–in “the cloud.” To do so, you need to be able to spin up a computing resource of the desired size, perhaps allocate persistent storage, set network interfaces, and configure backup systems and so forth based on the application’s needs. Ideally, you’d be able to do this in the same way on every cloud so that you could treat each cloud as effectively part of a single resource pool. But you can’t because different clouds have different application programming interfaces (APIs).

You can make a shim that achieves some interoperability by mapping basic cloud functions for different services.  However, getting beyond least common denominator translation of base-level functions is a trickier problem.  In cloud computing terms, imagine for example if one cloud provider offered just one size of VM while another let you configure a VM of arbitrary size. A lowest common denominator API would only let you create that single size of VM even when running on the more flexible platform."

What does Deltacloud do to solve this dilemma?  Here's the short-list of benefits that the Deltacloud API provides:

  • It can either be offered directly by the cloud provider, or by individual users running their own server
  • Client libraries can easily be written in any number of computer languages, and are already available for popular ones
  • The core API logic resides on the API server, enabling consistent behavior across all client libraries
  • Support for new clouds can be added to the API without changes to clients



"Deltacloud is written in Ruby (together with the Sinatra Web framework), but all communications from clients are handled through a REST interface, a widely-used style of lightweight client/server interaction. (For example, Amazon Web Services are accessed through REST interfaces in the vast majority of cases.) Deltacloud can then interface to existing cloud APIs through a modular chunk of code called a driver. Thus, different clients can support different computer languages and different drivers can support different target clouds without affecting the Deltacloud core. (Deltacloud can also support clouds directly with native code.)

Another advantage of this model is that the client and the target cloud are decoupled from each other. Different clients written in different languages can speak to an arbitrary set of supported clouds. This becomes particularly important when you consider that cloud computing introduces concepts such as resource abstraction which imply that workloads are largely insulated from operational details such as where they are going to run."

Deltacloud also abstracts the models and methods used by different public and private cloud providers down to a few fundamental approaches. The technology understands how a given cloud performs a given function and what resources a “small” VM instance, for example, includes on a given cloud.  You can also map defined hardware profiles for instances as closely as possible to the options offered by a given cloud.

To learn how you can join the Deltacloud effort, visit APIwanted.org, where external parties can submit suggestions for additional APIs and other desired functionality for Deltacloud.