This section discusses the main findings of our study, by answering the six questions presented in section 4.
RQ1: What are the definitions of “interoperability” in the context of cloud computing?
Several research papers we found in literature present definitions for interoperability (Dowell et al. 2011; Harsh et al. 2012; Loutas et al. 2011; Petcu 2013; 2014; Petcu et al. 2013; Petcu 2011; Rashidi et al. 2013; Rezaei et al. 2014), we present them next.
Definition 1
The IEEE Glossary (2013) defines interoperability as “the ability of a system or a product to work with other systems or products without special effort on the part of the customer”. According to this definition, interoperability is made possible by the implementation of standards.
Definition 2
A discussion group on cloud computing use cases11 defines interoperability in cloud computing as the ability to write code that works with one or more cloud providers simultaneously, regardless of the differences between platforms.
Definition 3
Rashidi et al. (2013) define interoperability in cloud computing as the ability of a service to interact with other homogeneous or heterogeneous services to improve its provided resources. The authors state that interoperability can be implemented under one or more domains, and that cloud services implemented in different layers12 are heterogeneous while those implemented in the same layer are homogeneous.
Definition 4
Dowel et al. (2011) state that cloud interoperability refers to the ease of migration and integration of applications and data between different cloud providers.
Definition 5
ISA (Interoperability Solutions for European Public Administrations)13 states that interoperability is the ability of systems and business processes to exchange data and to enable the distribution of information and knowledge.
Definition 6
Harsh et al. (2012) define interoperability as the ability of different heterogeneous systems to interact and function together. In cloud computing, interoperability could be defined as the ability of different applications to understand each other’s formats, Service Level Agreement (SLA) templates, authentication and authorization token formats and attribute data.
Definition 7
Rezaei et al. (2014) state that interoperability is a multidimensional concept and can be viewed from various perspectives and in different directions. Regarding interoperability in general (i.e., not only cloud interoperability) the authors identified four levels of interoperability issues, each one built on the top of the previous: Technical interoperability (Level 1), typically associated with hardware/software components, systems, and platforms, enabling machine-to-machine communication; Syntactical interoperability (Level 2), defined as the ability to exchange data. It is associated with data formats, and the messages exchanged in the communication must have a well-defined syntax; Semantic interoperability (Level 3), also related to data exchange, involves the interpretation of contents to give them meaning; and Organizational interoperability (Level 4), more related to the capability of organizations to exchange information regardless of the differences between the information systems being used. The success of the first three levels of interoperability forms the basis for organizational interoperability. They cite the definition used by Koussouris et al. (2011) that seem cloud interoperability as the ability of cloud services to work with different cloud services and providers, and other applications or platforms that are not cloud dependant. According Rezaei et al. (2014) cloud interoperability fits in level 3.
Definition 8
Petcu (2011) defines interoperability as a general property that refers to the ability of many systems or organizations to work together (inter-operate). From a general computing perspective, this means that data can be exchanged and used by two or more systems or components. However, for the cloud, Petcu goes beyond this simpler perspective, listing different abilities that are normally associated to cloud interoperability:
-
“the ability to abstract the programmatic differences from one cloud to another”;
-
“the ability to translate between the abstractions supported by different clouds”;
-
“the ability to flexibly run applications locally or in the cloud, or in a combination”;
-
“the ability to move applications from one environment to another or run in multiple clouds”;
-
“the ability to move services, processes, workload and data between clouds”;
-
“the ability to use the same management tools, server images and software in multiple clouds”;
-
“the ability to communicate between providers, porting applications and data between them”;
-
“the ability to federate multiple clouds to support a single application”.
Thus, there are many distinct definitions of interoperability, but they cannot always be applied to the same context. In general, we observed that interoperability is often associated with many of the advantages of the cloud model. Therefore, we need a more precise definition, a more specific one that is aligned to how interoperability has been implemented in practice.
Some of the reviewed definitions emphasise communication (e.g., Definitions 5 and 6), focusing on data and information exchange between systems. Other definitions mention properties related to platform independence, emphasizing ease of use (Definition 1), programming for different platforms (Definition 2), ease of migration (Definition 4) and support to different service levels (Definitions 3 and 8). However, in our view, this platform independence is more related to portability. As pointed out by Petcu (2011), while interoperability is the successful communication between or among systems, portability is the ability to use components or systems lying on multiple hardware or software environments. From Definition 7, interoperability in cloud computing is at level 3, and traditional systems interoperability is at level 1. One final observation about these definitions is that interoperability can also means the integration between cloud providers. This is suggested by Petcu (Definition 8), who mentions the abilities to communicate between providers, to use the same management tools and software in multiple clouds, and to federate multiple clouds to support a single application. Derived from these observations, we propose the following definition: cloud interoperability refers to the ability to develop applications that combine resources that can inter-operate, or work together from multiple cloud providers, hence taking advantage of specific features provided by each provider. As example of this definition could be an application that part of it uses resources provided by Google App Engine, part uses resources provided by Windows Azure and part uses resources provided by any third provider.
Our definition is simple and enjoys a good abstraction level, but it is quite restrictive, it refers to cloud applications that use specific services from many providers and not to the communication between the infrastructure services between two cloud provider in agreement to share resources. However, we believe that cloud interoperability is not restricted to a particular strategy. More importantly than using standardized data exchange formats, integration of services/providers in different levels or federated clouds14, is the final goal of building applications that can benefit from many cloud providers, without requiring too much effort from the developer. Therefore, our definition will probably evolve, as research in cloud interoperability is still far from mature. Many definitions, approaches, and, consequently, requirements and applications, may appear as research in the field advances.
RQ2: What are the concepts related to cloud interoperability?
In this review, and based on (Dowell et al. 2011; Grozev and Buyya 2014; Kostoska et al. 2012; Liu et al. 2011; Loutas et al. 2011; Petcu 2014; Rashidi et al. 2013; Zhang et al. 2013), we identified four concepts that are normally associated with cloud interoperability: Inter-Cloud computing, Cloud Federation, Multi-Cloud Environment, and Cloud Brokering.
Inter-Cloud computing is a “cloud model that, for the purpose of guaranteeing service quality, such as the evaluation and availability of each service, allows on-demand reassignment of resources and transfer of workload through a interworking of cloud systems of different cloud providers based on coordination of each consumer’s requirements for service quality with each provider’s SLA and use of standard interfaces” (Grozev and Buyya 2014; Petcu 2014). This means that applications, or parts of an application, can be deployed into, and take advantage of, more than one cloud system. Benefits include increased support for diverse geographical locations, and giving developers a fine-grained control as to where resources are positioned. Inter-cloud also results in better application resilience, since with multiple supporting clouds there is no single point of possible service outage. Also, by using multiple clouds, a customer can easily avoid vendor lock-in (Grozev and Buyya 2014).
If individual cloud providers voluntarily participate to form an Inter-Cloud environment, the result is called a Cloud Federation (Grozev and Buyya 2014). This means that the providers knowingly collaborate to interconnect their infrastructure in order to allow resources to be reassigned among them. This kind of Inter-Cloud is normally adopted by governmental or non-profit organizations, since in these cases the individual providers share the common interest of increasing overall service quality and availability.
If providers are unaware of the connection, i.e. clients and/or services are the sole responsible for managing resource provisioning over multiple providers, the environment is a Multi-Cloud environment (Grozev and Buyya 2014). This kind of Inter-Cloud is normally adopted with independent providers, such as large commercial companies like Amazon and Google. These providers normally have no interest in sharing their resources, preferring customer exclusivity.
In order to make Inter-Cloud computing possible, a service is required for dynamic provisioning resources, deployment of application components into these resources, and redirecting incoming requests to the allocated resources (Grozev and Buyya 2014). This service is called cloud brokering. According to NIST (Liu et al. 2011), a cloud broker is a cloud computing actor that manages use, performance and delivery of cloud services, and negotiates relationships between many providers and cloud customers. In a multiple cloud setup, a broker could help find and manage cloud services.
Similarly to the state of cloud interoperability definitions, cloud interoperability concepts are still evolving. Petcu (2014) presents a list containing “top 25” categories of multiple clouds. However, we believe that, in essence, most of the concepts presented in her work, raise from the four highlighted here.
RQ3: Is there a classification of interoperability approaches?
Petcu (2011) identified various criteria to classify the types of cloud interoperability. These criteria refer to a classification of the solution itself, depending on the implemented interoperability strategy. They are:
-
1.
Agreement Level: this level refers to the contract between two systems that need to interoperate. There are two types of agreement:
-
Syntactic interoperability: when systems can communicate and exchange data with a specific data format and communication protocols;
-
Semantic Interoperability: when there is a significant and accurate automatic interpretation of data exchanged to produce useful results (usually using a common reference model in this communication).
-
2.
Adoption Level: when two or more cloud systems need to interoperate, a decision must be taken about which technology, standard or message format should be used:
-
Interoperability by design: when there is a standard documentation to develop interoperable products;
-
Post-facto interoperability: when, after releasing, a technology becomes dominant in the market. Remaining products that need to communicate with it need to adopt the same format already used in the dominant technology.
-
3.
Deployment Level: this type of interoperability refers to how service integration occurs regarding the different cloud levels (IaaS, PaaS, SaaS). It can be:
-
Horizontal interoperability: when services work together at the same deployment level, e.g. SaaS-SaaS, PaaS-PaaS and IaaS-IaaS;
-
Vertical interoperability: when services work together in different deployment levels, e.g. PaaS-SaaS and SaaS-IaaS.
-
4.
Patterns of interactions between clouds: this level refers to how interaction between cloud applications occur. It can be:
-
Synchronous interoperability: direct calls only for very specific real-time applications where the response time is critical;
-
Asynchronous interoperability: applications are loosely coupled so that applications do not wait for a response.
Besides these four levels of agreement identified by Petcu, we identified a fifth one, defined as follows:
-
5.
End-user level: this level considers the end user of the interoperability solution, and it can be:
-
Provider-centric interoperability: when the interoperability strategy focuses on making the providers’ systems interoperable (Zhang et al. 2013). Examples of this type of interoperability are solutions based on standards like Cloud Data Management Interface (CDMI), Open Cloud Computing Interface (OCCI), and Open Virtualization Format (OVF).
-
User-centric interoperability: when the focus is on the interoperability of applications, from the perspective of the users (Zhang et al. 2013). These solutions help users of different cloud services find a common denominator between the services (Zeginis et al. 2013). Examples of user-centric interoperability approaches (Zeginis et al. 2013) are mOSAIC (Rak et al. 2011) and Cloud4SOA15.
Another possible classification is according to the technology used to implement the interoperability solution (Petcu 2011). The most common implementation choices (Petcu 2011) are: Open APIs, Open protocols, Standards, Layers of abstraction, Semantic repositories, and Domain-Specific Languages. We do not describe these in detail because they are all well-know concepts, and their exploration is not in the scope of this work.
In this survey, we also found a category of cloud interoperability solutions based on MDE (Model-Driven Engineering) (Brunelière et al. 2010; Ferry et al. 2013; Sharma et al. 2011; Sharma and Sood 2011) and related technologies. These use platform-independent models and code generation for the creation of interoperable software. We also identified some SOA-based approaches (Mei et al. 2009; Papazoglou et al. 2007; Sharma et al. 2011), which are solutions that use SOA (Service-Oriented Architecture) technologies to allow different systems to interoperate regardless of where they are deployed. It is possible that some other categorization can raise as research and interoperability technologies advances.
RQ4: What are the requirements and possible usage scenarios for a cloud interoperability solution?
Petcu (2013) identified many requirements that should be implemented in solutions and consequently need to be satisfied by developers to build Inter-Cloud environments. She classifies the requirements in three groups: development, with requirements related to the development of services and applications, deployment, with requirements related to how applications can be deployed over multiple clouds, and execution, with requirements related to how applications execute and are monitored in multiple clouds. Additionally, she identifies a set of usage scenarios. These require solutions more focused in migration strategies between clouds to avoid lock-in and interface across multiple clouds to manage services from different clouds (brokerage service). Some of the usage scenarios include:
-
optimizing costs and improving quality of services (QoS);
-
reacting to changes in technologies and services offered by providers;
-
adapting to rules and laws according to each country and enterprises;
-
replicating applications or consuming services from different providers to ensure availability on the Web;
-
avoiding dependence on specific providers;
-
ensuring backups;
-
acting as a broker mechanism; and
-
combining different services offered by different providers to build a new improved service.
These usage scenarios and requirements reinforce the importance and necessity of developing cloud interoperability solutions. As technologies related to interoperable solutions advances, many other usage scenarios can raise and become relevant. Some scenarios that were not mentioned in surveyed studies are mobile cloud applications and cloudlets. As cloud computing in general advances, many other research fields and technologies can benefit from it. Among main advantages of cloud model is the combination of its services with spread computing potential as in mobile devices.
Benefits of interoperable solutions are many and directly aligned with above listed requirements and scenarios. (A full list can be seen in (Petcu 2013), although no detailed discussion is included.) Analyzing which solutions are aligned with each of those scenarios and requirements is out of the scope of this work.
RQ5: What solutions for cloud interoperability exist and what are their characteristics?
Cloud interoperability is an extensive subject. While many solutions in the literature exist, new ones are appearing as technology becomes better established. Despite the careful conduction of this literature survey, and the rigour in searching, extracting and analysing data, its results are limited to research papers we found. It is not always that all available papers are found. In practice, a research group always tries to find as much studies as possible, but after publishing the paper, the results and catalog may rapidly become obsolete. In an ideal scenario, it would be much more useful to keep a Wiki, like the one maintained by Cloud Standards16 and allow authors of new solutions to update the list and present their approaches to the community.
Despite that observation, in this work it would be impractical to describe all the solutions found. So we only included those that were more referenced in previous research papers we found (Grozev (2014) and Petcu (2014) also present catalog of solutions). We tried to categorize the solutions according to the observations discussed in RQ3.
Standardization: according to Armbrust et al. (2009), one way to solve interoperability is through standardization. If enough cloud service/providers successfully adhere to the standards, applications could then be more easily ported and interoperability is facilitated17. Standardization efforts include: Distributed Management Task Force (DMTF), Cloud Standards Coordination (ETSI), Advancing Storage and Information Technology (SNIA), CloudAudit, Cloud Security Alliance (CSA), TC CLOUD, Object Management Group (OMG) and IEEE. However, although standardization is important, its success depends on adoption. This means that cloud providers must all agree and follow a standard. As discussed in Section 5.3, while public and governmental cloud providers share a common interest in collaboration, most independent commercial vendors have no interest in allowing their customers to easily migrate away from them. For this reason, in determined contexts, standards may not be the best solution. Adopting a standard can also lead the consumer to become locked-in in selected one. There are so many standards that even choosing one may become a challenge. Thus, the effort required to choose one standard should not be disregarded. Also, there are no guarantees that the chosen standard will become a success, therefore increasing the risk that needs to be managed by cloud adopters/providers.
Abstraction Layers: some initiatives are trying to achieve cloud interoperability through abstraction layers. This consists in abstracting some common feature of each cloud provider and offering a high level layer to make the development more platform-dependent. Projects RESERVOIR, SLA@SOI and CSAL18 are examples of initiatives following this idea.
Open protocols: this strategy is more focused on a communication protocol between the platforms. Examples of open cloud protocols are OCCI and DeltaCloud. Examples of proprietary protocols are Amazon EC2 or VMware vCloud.
Open APIs: an API is a set of tools and protocols for building applications. In cloud computing, there are APIs that target interoperability, such as Jclouds, GoGrid, OpenStack, Simple Cloud and CloudLoop.
Model-driven approaches: despite the advances of software development techniques, concerns about reuse, productivity, maintenance, documentation, validation, optimization, portability and interoperability are still under discussion. MDE aims at solving some of these issues (Kleppe et al. 2003), shifting the focus of modern development methodologies from implementation to conceptual modeling. Thus, models are now first-class citizens, and transformation mechanisms are used to generate code from them, reducing development effort, increasing portability and interoperability of software systems (France and Rumpe 2007).
Sharma and Sood (2011) present a model-driven approach for interoperability in SaaS (Software-as-a-Service). They define models at different abstraction levels, based on separation of concerns, particularly Computation Independent Model (CIM), Platform Independent Model (PIM) and Platform Specific Model (PSM) of the MDA19. Each level can be composed by one or more models to specify the structural, functional and behavioral features of a system. For PIMs, a formal definition of the operations offered by the service is used, which can be accessed through an interface that must later be composed with other services to build a complete system. Business rules are specified through the declaration of restrictions, pre-conditions and post-conditions, and invariants in Object Constraint Language (OCL). After some transformations the PIM is converted to a Web-Service Description Language (WSDL) PSM, which consists of a specific model description language for web services. The final step is the transformation of the WSDL PSM into WSDL specifications.
The MOdelDriven Approach for the design and execution of applications on multiple Clouds (MODACLOUDS) aims at supporting system developers and operators in exploiting multiple clouds and in migrating their applications from cloud to cloud, as needed (Ardagna et al. 2012). MODACLOUDS main objective is to provide methods, a decision support system, an open source IDE and runtime environment for the high-level design, early prototyping, semi-automatic code generation, and automatic deployment of applications on multiple clouds. It also helps administrators to monitor the services and measure their quality. By the time this paper was written, the framework was still under development20, but it intends to provide one of the first implementation of OASIS TOSCA emerging standard. MODACLOUDS also includes the development of CloudML, a domain-specific modeling language and runtime environment that facilitate the specification of cloud application provisioning, deployment, and adaptation.
SOA-based solutions: there are some strategies based on Service-Oriented Architecture for cloud interoperability. For example, Cloud4SOA presents a broker-based architecture to address interoperability in PaaS model (Zeginis et al. 2013). The system enables management, monitoring and migration through the interconnection between different PaaS providers that share the same technology. The main idea behind this solution is to facilitate developers during search, deployment and governance of PaaS applications to better meet their demands. Semantic algorithms implemented in Cloud4SOA allow management of data and applications. They enable portability between PaaS that use same technologies but have different APIs and data models (Zeginis et al. 2013). In practice, Cloud4SOA is more focused on portability concepts.
mOSAIC is a project aiming at offering a simple and clear access to heterogeneous resources from multiple clouds. It is a vertical interoperability strategy targeting hybrid clouds (Petcu 2011). Under a high-level perspective, mOSAIC is composed of an API and a PaaS that allow to deploy and manage applications. It offers an abstraction layer and applies web semantic to the implementation its interfaces and components (Petcu 2014). In short, this solution is a PaaS that allows development, configuration and management of applications running on IaaS (Petcu 2014).
RQ6: are there any evaluation models for cloud interoperability solutions?
We found a previously published work on evaluation models for interoperability (Rezaei et al. 2014) which describes existing models and offers a comparative analysis highlighting major similarities and differences between them. However, the authors conclude that these existing interoperability evaluation models are not applicable to cloud computing. We too, could not find any evaluation model for cloud interoperability in the selected studies. This may suggest an open challenge to be addressed in the future. Such an evaluation model for cloud interoperability could be a good contribution to this area of research. We believe Rezaei et al. (2014) work can serve as basis to propose some evaluation model. Due heterogeneity of interoperable cloud services, their usage scenarios and requirements, we believe only one model for evaluating is not enough. It is needed to propose many models, each one aligned with the context of interoperability strategy.