API Compatibility War Validates Abstraction Approach to Cloud Computing

Pete Johnson holds the position of senior director of business development for CliQr Technologies. Johnson is active on Twitter, @nerdguru.

As you may know, the U.S. Court of Appeals for the Federal Circuit ruled that Oracle can copyright the Java API and Google violated that copyright by creating software that is API compatible. This has huge impact across the entire software world, but in particular with cloud computing where the APIs are used to provision resources on demand.

This development sheds light on the desire for users to avoid lock-in and have the ability to more freely move applications between clouds, which can be done more easily with API compatibility. But it also sheds light on the alternative of an abstraction approach that frees cloud vendors to innovate beyond borders imposed by API compatibility while giving users the portability they seek.

API compatibility has been a hot topic in cloud computing for quite some time. In fact, last summer Cloudscaling CEO Randy Bias and Rackspace Evangelist Robert Scoble had a very heated and public debate around whether or not it was in OpenStack’s best interest to provide full AWS API compatibility.

On the flip side, IBM has invested in the Jumpgate project, making it much easier for non-OpenStack-based clouds to achieve OpenStack API compatibility. This Oracle vs. Google ruling puts those efforts into legal limbo as cloud users see API compatibility as a way to more freely move workloads between cloud vendors without having to change their often hand-crafted tooling.

Should cloud compatibility really be at the API?

The question this raises is where should the enablement of cloud portability really reside?  Cloud customers today, especially Enterprise IT departments who are wary of vendor lock-in want the ability to run workloads on different clouds as the market pricing and features change over time.  Many argue that a multi-cloud strategy is best given the degree of High Availability and Disaster Recover you can achieve with that approach. Also, different kinds of workloads run differently on various public and private clouds so to assume they will all run best on a single target is naive.

One way for end customers to achieve this cloud portability would be to use a common API across all possible vendors. Even before this legal ruling and well after the ultimate outcome, the likelihood of a single industry-wide API is doubtful because cloud vendors want to provide feature differentiation, which gets diluted if features have to get dumbed down to support API compatibility. Fortunately, there is another approach that gives users the portability they want without restricting cloud vendors to a common API.

Validation for an abstraction approach

This legal issue is helping point out that the right way for customers to freely move workloads across different clouds isn’t with a common API, but with an abstraction layer that can interpret the strengths and weaknesses of each offering and provision resources that applications need to run optimally on each cloud accordingly.

Many Cloud Management Platforms (CMPs) support this notion as a way to achieve the same portability effect as a common API by acting as an intermediary but without restricting innovation for the cloud vendors.

The technique CMPs use typically involves creating a meta-data description of the application’s requirements related to core primitives such as compute, storage, network, security, etc. without having to define cloud-specific infrastructure. Typically done in an application profile, template or blueprint, after completing through manual or automated means, the completed application profile can be used to natively deploy the application onto and move between any supported private or public cloud environments, unaltered, remaining portable and manageable.

In addition to the application profile, a key enabler of this abstracted approach is a cloud orchestrator. Often a single, multi-tenant virtual appliance that resides transparently on each supported private or public cloud, this orchestrator is responsible for coordinating the requirements of the application, represented by the output of the application profile, with the best-practice infrastructure and services of the cloud, allowing it to provision its resources in order to deploy the application.

In this model, the onus is on the CMP to constantly update its cloud orchestrators to take advantage of innovations of each cloud vendor, who no longer needs to be concerned with breaking API compatibility. Because of the abstraction approach, however, the user is insulated from such changes and simply inherits the benefits as they are written into the cloud orchestrator by the CMP. Centralizing specific cloud vendor expertise at the CMP, shielding the end user through the application profile abstraction, and freeing the cloud vendor from a specific API benefits everyone in the ecosystem.

Abstraction insulates from change

Regardless of how the legal issue plays out, and many experts feel it is likely to be overturned on appeal, the point it raises about where the best place is in the technology stack to ensure customers have choices is the same. Even if they could legally do so, cloud vendors will never be 100 percent API compatible across platforms because it limits their ability to innovate. By abstracting functionality above the API in a way that enables best use of features present in one vendor that are absent in another, customers get the portability they want while still having the ability to take advantage of cloud-specific features as needed.

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.