Interoperability is used in various levels of software and systems. With Cloud Computing, several major interoperability questions arise. First of all, interoperability can be seen as an infrastructure interoperability element. As for infrastructure interoperability, it is basically about the question on how to move virtual instances from one cloud provider to another.
Another interoperability question is about software and tools interoperability. This is not on how to transfer software from one provider to another, it is about how different software languages and tools collaborate in one cloud ecosystem or different cloud ecosystems. An example of that is a message-based communication between a Java-based solution and a Microsoft .NET solution. Mayrbäurl et al. described such a scenario on a Microsoft Azure based solution that itself communicates with an on-premise solution that is written in Java, whereas the Cloud service uses .NET [May11].
The third interoperability question is about the services offered by different distributors. When someone builds a cloud solution based on a specific provider and uses a software stack such as J2EE or Microsoft .NET, it is not that difficult to move the application to another instance or Cloud provider. However, when this application consumes platform-specific services such as a distributed storage service, a messaging service, e-mail and alike, migration becomes challenging. Therefore, providing interoperability on the platform services level is another key issue in Cloud computing interoperability.
Gonidis et al. defines Interoperability with two different characteristics [Gon11]. According to this paper, interoperability is when two components in different cloud environments are collaborating, whereas the possibility to move from one cloud platform to another is portability. Liu et al. defines portability itself with system portability, which means that a virtual machine can easily be moved to another cloud provider’s platform [Nis11]. In general, they define portability with the ability to move an application and all it’s data with little effort from one cloud provider to another cloud provider.
As for interoperability and portability, current literature knows different approaches. In Gonidis et al. portability and interoperability are distinct features [Gon11], whereas Dowel et al. defines portability to be a subset of interoperability [Dow11]. Petcu et al. discusses interoperability consisting of two dimensions: a horizontal dimension and a vertical dimension [Pet11]. Horizontal interoperability (as illustrated in figure 2) means that two cloud services on the same service level (e.g. PaaS) can communicate with each other, whereas vertical interoperability describes the ability to host an application on different cloud providers. When implementing vertical portability, it is necessary to support different cloud platforms.

Another description of interoperability for cloud solutions is given by Parameswaran et al. [Par12]. The authors describe 4 major factors of interoperability challenges. The first is portability, which was already discussed. The second is interoperability itself, which focuses on efficient and reliable protocols. The third is heterogeneity. This states that there are several protocols such as SOAP and Representational State Transfer (REST) [Fie00] and different formats such as XML and JSON. A PaaS application will need to deal with all of these protocols and formats in order to ensure interoperability in a heterogeneous environment. Last, there is geo-diversity. This means that smaller, but geographically more distributed datacentres might be more effective than large datacentres that are only available in some regions.
Why is interoperability so important to the cloud?
Leavitt [Lea09] addresses potential issues with the vendor Lock-In in cloud computing. When it is not possible to move from one platform to another at low cost and effort, it is very likely that one get’s locked into a certain platform. Should the provider decide to increase prices, the customer has to stick to the new conditions without the ability to move the application to a cheaper carrier. Another reason is when the cloud provider fails. Even large providers such as Microsoft [Oky14] and Amazon [Kep14] fail. This could mean that the platform is not available for several hours to days. In their SLA’s, cloud providers typically don’t reimburse the customers for lost revenue [Ama14b], [Mic14c]. But it could become worse: the cloud provider might actually disappear and customers have to move entirely to another platform entirely. This happened in February 2009 when Coghead, a cloud Platform went out of service [Kin09]. Users could export their data, but couldn’t port their applications.
This post is part of a work done on Cloud interoperability. You can access the full work here and the list of references here.