Trend Cloud Security Blog – Cloud Computing Experts

Cloud Computing Standards, Dream vs. Reality

Portability and interoperability in cloud computing may seem tangential to security, but avoiding vendor lock-in is about more than having access to competitive pricing or better service. When relying on a single provider there is inherent risk, especially in the availability of the service and data.

Throughout history the need for portability and interoperability has usually been dealt with through standardization. Standard railroad gauges enabled cross continental travel, just as TCP/IP unlocked worldwide communications. It’s not surprising then, that many people look at cloud computing and assume we need standards before lock-in can be avoided. But do we really need widely-adopted standards? While not ideal, interoperability can still be achieved through abstraction (or brokering) and portability through conversion in an environment with many standards.

When talking about interoperability and portability in Infrastructure-as-a-Service (IaaS) there are generally two significant issues. One is the format of the virtual machine templates (or images) which describes the disk and configuration of the virtual resources required. While this is generally dictated by the underlying virtualization solution used, some providers have created custom formats (for example, the Amazon Machine Image). The Open Virtualization Format (OVF) was designed as a single standard, but public providers may continue to push their own formats for various reasons. Without universal adoption of OVF, the next best thing is format conversion to provide practical portability. As a stop-gap, some service providers have started accepting multiple formats to avoid the conversion overhead, in the same way some devices supported HDDVD and Blu Ray until that standards battle was won.

The other challenge is the current incompatibility of the management API for uploading, downloading, inspecting, configuring, and performing actions (such as spinning up new instances). Each provider has its own API which prevents orchestration software from working with multiple service providers. There are many approaches to this issue. Some groups like the Open Grid Forum are attempting to create a standard, the Open Cloud Computing Interface (OCCI). Others, like Eucalyptus emulate the Amazon Web Services interface as a de facto standard. VMware has developed its own vCloud API which it submitted to the Distributed Management Task Force (DMTF) as an open standard. vCloud API will provide a basis for interoperability among VMware-based service providers (and perhaps other providers in the future), but almost certainly not the established players. Most providers forgo official standardization because they want (and need) to move rapidly in this evolving marketplace and standards bodies are not known for speed. But the lack of industry-wide adoption of a single API doesn’t have to prevent portability and interoperability.

Multiple APIs can be combined under a single API, even without participation of the providers. In the virtualization space, an API for the APIs already exists in the form of libvirt. For cloud computing, a group has taken on this task for with the Unified Cloud Interface Project, though the project is still in its infancy. Another initiative, cloudloop provides an API to work with multiple storage services. An API of APIs, such as these, provides a form of interoperability, where framework vendors, middleware vendors, and end users can consume a single API without worrying about service provider lock-in.

For Platform-as-a-Service (PaaS), portability and interoperability becomes much more challenging. By nature platform services can have drastically different data formats. Windows Azure, for example, provides database services and .NET application containers. Applications and data within Azure are not compatible Google AppEngine and vice versa. The only way to avoid lock-in when utilizing PaaS is to choose a framework offered by multiple providers and avoid provider specific extensions (like the Python extensions in AppEngine). We may see a similar abstraction strategy emerge where applications can be written once to run on many PaaS offerings. I expect to see a lot of development in this space as workloads shift from IaaS to PaaS.

Software-as-a-Service (SaaS) has the most challenge because of the inherent diversity of the data. One can’t expect Facebook data to be exportable and importable into another social media site (Matt Asay called this the Hotel California of Tech). Nor can we assume all software services even offer extraction of data. This is only acceptable when the service provided doesn’t have existing standards. In cases like Google Docs, it is reasonable to expect some form of conversion like the new export options Google released this week. In this environment conversion is a much more practice vehicle for portability rather than standardization.

In the rapidly evolving cloud computing marketplace, we should expect to see multiple standards emerge and as Stephen Foskett said “only useful standards will survive“. This is a healthy process in a new environment. In the mean time we can achieve portability and interoperability independent of the standards. We can break vendor lock-in and ensure the availability of services and data through conversion and abstraction.