Issues on developing interoperable cloud applications: definitions, concepts, approaches, requirements, characteristics and evaluation models

2.1 Search for similar studies

Before starting such a study, it is wise to check if a similar study already exists. We performed an ad-hoc search for cloud interoperability and cloud computing in general.

2.2 Search strategy

To define our search strategy, we identified the keywords and synonyms related to the subject of our research, the source selection criteria, accepted languages, search methods, study selection criteria, definition of study types, initial and selection process. We defined, tested and consequently used several strings. We also used snow bowling technique and included many references cited by studies we found in our searches. A specialist about the subject informed us that Armbrust et al.’s paper is among most cited (Armbrust et al. 2009), thus we considered to verify manually all papers that cited their job in order to manually include relevant ones in our research.

In what concerns the search methods, we first defined the search string based on the identified keywords from the Scopus database. This string was then translated to the formats accepted by each library. Our generic search string was: TITLE-ABS-KEY((“Cloud Computing”) AND (“interoperability” OR “interoperable”)). This string is quite comprehensive as our goal is to retrieve the maximum number of potentially relevant studies. For the two other sources (related work and selected conferences and journals) we performed manual searches by browsing their respective proceedings and websites.

Regarding the definition of study types, we considered both primary and secondary studies, including technical reports⁶. The initial selection process included only papers retrieved automatically from the digital libraries. The decision about inclusion and exclusion of each retrieved work was first based on their titles and abstracts, and, when necessary, we also read the concluding remarks and related work sections. During the second selection process, each study retrieved from the initial selection was fully read and analysed according to the inclusion and exclusion criteria. Notice that we did not evaluate the studies against any quality evaluation criteria, basically being interested in any relevant study.

After the initial study selection, we initiated the extraction process. The data extraction form fields were:

Contextualization (aiming at extracting the context of the proposed solution), interoperability definition, problem definition, solution classification, evaluation method, metrics and observations. (The observations field contains general impressions and relevant concepts found in the study.)

The approach for summarization of results although we performed a qualitative analysis on the extracted data, we did not use any form of meta-analysis or quantitative methods, because the research questions did not require such analysis.

2.3 Execution

The execution consists in applying the research plan, which includes selecting the studies, extracting the data, and answering the research questions. This section presents the most relevant information about the execution of this review.

This step searches for studies by following the search method defined in the protocol. Regarding manual searches, we first checked the list of papers published in each selected conference and journal and then used Google Scholar to retrieve the studies. We retrieved 401 studies from Scopus, 65 from IEEE, and 3 from ACM. Additionally, 14 were found manually from selected conferences and journals.

As predicted, most results come from the Scopus database, since it searches other databases such as IEEE and ACM. Thus, using Scopus together with databases it indexes increases the amount of studies retrieved, as well as duplicates.

We performed searches between 2015/October and 2016/May. In the first selection, from the 483 studies initially retrieved, 386 were excluded. In the second selection, from the remaining 97 studies, 51 were accepted, 38 were rejected and 8 were found duplicated.

The full text of the all papers selected were analysed and the data extracted from them was stored in the extraction forms. To summarize results we performed a qualitative analysis of the results (Cruzes and Dyba 2011), as our research questions did not require a quantitative analysis. Following sections discuss the main findings of our study, by answering defined questions.

5.1 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.

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 clouds¹⁴, 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.

5.2 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.

5.3 RQ3: Is there a classification of interoperability approaches?

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.

5.4 RQ4: What are the requirements and possible usage scenarios for a cloud interoperability solution?

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.

5.5 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 Standards¹⁶ 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 facilitated¹⁷. 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 CSAL¹⁸ 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 MDA¹⁹. 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 development²⁰, 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).

5.6 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.