The Deltacloud Project Reaches 1.0

From our perspective, the future of cloud computing is open. This requires more than open source code, important as that is. It also requires, among other attributes, APIs that are open, pluggable and extensible. This lets users add features, providers and technologies from a variety of vendors or other sources. Critically, the API itself cannot be under the control of a specific vendor or tied to a specific implementation, but must be under the auspices of a third-party organization that allows for contributions and extensions in an open and transparent manner.

This is a pretty good description of the approach taken by the Apache Deltacloud Project. Deltacloud was initiated by Red Hat and is now a project hosted at the Apache Software Foundation. The community that has grown around Deltacloud develops it under and is governed by the ASF's collaborative and meritocratic principles. Deltacloud's fundamental goal is to abstract differences across clouds. It does so using a variety of techniques that provide consistency while making it possible to leverage functionality present within different clouds to the maximum degree possible. For example, a technique known as introspection lets cloud providers advertise optional capabilities, which can then be used when present. All of this helps avoid the “lowest common denominator” problem that can be an issue with cross-platform APIs.

Deltacloud's goal, therefore, is not to be yet another cloud provider API but to meet the needs of users who want to be able to operate a hybrid cloud computing environment as seamlessly as possible. (Red Hat CloudFormsTM is an open hybrid cloud management product that leverages Deltacloud as one of its upstream projects for just this reason.)

Deltacloud is also a highly modular architecture, which provides a great deal of choice in both how users communicate with Deltacloud and which cloud providers it supports.

With its 1.0 release, Deltacloud offers a variety of front-ends, which is to say interfaces through which users make a request to a cloud provider. New is a basic Amazon EC2 front-end, which can be used to communicate with a variety of cloud providers using the popular Amazon Web Services interface. This is primarily intended for users looking to migrate between EC2 and another cloud provider.

This new EC2 interface joins the RESTful front-end that implements the Cloud Infrastructure Management Interface (CIMI) from the DMTF's Cloud Management Working Group. CIMI defines a logical model for the management of resources within the Infrastructure-as-a-Service (IaaS) domain. This standards effort has gained broad industry support; the draft model and protocol lists over 60 contributors or authors. For those interested in nitty-gritty detail about CIMI, a variety of detailed work-in-progress specification documents can be found on the DMTF site.

There's also a Deltacloud “classic” RESTful front-end that implements an API developed prior to the availability of the CIMI work within the DMTF.

Deltacloud's back-end, i.e. what talks to the cloud providers themselves, is equally modular. Cloud provider-specific code is encapsulated within what's called a “driver.” This allows support for new cloud providers to be implemented independently of other components of Deltacloud. Among other advantages, this makes it easier for cloud providers to write their own drivers should they wish to do so.

The Deltacloud driver list is already quite expansive. The full support matrix is available on the project site, but it includes compute and/or storage providers for cloud providers such as Amazon, Rackspace, Fujitsu Global Cloud Platform, IBM Smart Business Cloud, OpenStack, Red Hat Enterprise Virtualization and VMware vSphere. (In this context, “cloud provider” means any infrastructure that can provide resources for a hybrid cloud—including virtualization management platforms.)

Combine the modular front-end and the modular back-end and you get what David Lutterkort, chair of the Apache Deltacloud Project Management Committee and Red Hat Principal Software Engineer, calls an “n:m proxy.” A front-end talking to a back-end. Talk industry-standard CIMI to a public cloud with a provider-specific API. Talk Amazon EC2 to OpenStack. And do so using client libraries written for a wide variety of languages. Your choice.

Learn more about Deltacloud here. Learn more about Red Hat CloudFormsTM here.