Cloud Computing Interoperability Approaches – Possibilities and Challenges Magdalena Kostoska Marjan Gusev Ss. Cyril and Methodius University Ss. Cyril and Methodius University Faculty of Information Sciences and Computer Faculty of Information Sciences and Computer Engineering Engineering 16 Rugjer Boshkovikj 16 Rugjer Boshkovikj Skopje, FYR Macedonia Skopje, FYR Macedonia magdalena.kostoska@finki.ukim.mk marjan.gushev@finki.ukim.mk Sasko Ristov Kiril Kiroski Ss. Cyril and Methodius University Ss. Cyril and Methodius University Faculty of Information Sciences and Computer Faculty of Information Sciences and Computer Engineering Engineering 16 Rugjer Boshkovikj 16 Rugjer Boshkovikj Skopje, FYR Macedonia Skopje, FYR Macedonia sashko.ristov@finki.ukim.mk kiril.kjiroski@finki.ukim.mk ABSTRACT applications running in different clouds to share data, appli- The Cloud Computing Interoperability (CCI) is a hot re- cation to be transferred to another cloud solution or having search topic and has been addressed by many scientists, same functionalities and options in different cloud platforms architects, groups etc. A lot of different approaches and or solutions. Also data and images portability, management possible solutions are published, but there is no accepted and migration among different cloud solutions are not ex- standard or model yet. This paper is a survey of the most cluded. The interoperability may be defined on every level influential published CCI models and discusses their pos- of the cloud computing service stack: Infrastructure as a sibilities and challenges. The accent in this paper is set to Service (IaaS), Platform as a Service (PaaS) and Software analysis of the Software as a Service (SaaS) CCI model based as a Service (SaaS). on adapters. In this paper we will use the definition given by Enterprise The current state of the cloud computing market and the Interoperability Science Base (EISB) Glossary [2]. results of recent Cloud Computing (CC) market surveys are also included in our analysis. Definition 1 (Cloud Computing Interoperability). The presented conclusion addresses the increasing trend in Cloud interoperability is the ability of cloud services to be the usage of cloud computing and the lack of visible result able to work together with both different cloud services and to achieve cloud computing interoperability. So the next providers, and other applications or platforms that are not logical step is to create adapters to achieve interoperability cloud dependant. [2] at the SaaS level. [14] is one of the first papers that suggests the need for cloud computing ad CCI and describes possible scenarios for Categories and Subject Descriptors CCI. As cloud computing became more widely used technol- D.2.0 [Software Engineering]: General—Standards; D.2.11 ogy, the CCI has been analyzed by more research communi- [Software Engineering]: Software Architectures; D.2.12 ties. Yet, there is no unique solution on the horizon. [Software Engineering]: Interoperability In this paper we will represent and analyze some of the suggested models for interoperability, analyze the current state of the market and forecast future direction for devel- Keywords opments. Cloud computing, interoperability, comparison Section 2 presents the results from CC surveys and gives overview of the current state of the CC markets and cus- tomers opinions. Section 3 presents published CCI models 1. INTRODUCTION and their current progress and also describes new CCI ap- There are different perceptions of the term Cloud Com- proach. Section 4 evaluates the presented models. puting Interoperability (CCI) defined by different points of views [13] [10] [15]. This term may be referred as ability of 2. CURRENT STATE OF CLOUD COMPUT- BCI’12, September 16–20, 2012, Novi Sad, Serbia. ING MARKET Copyright c 2012 by the paper’s authors. Copying permitted only for private and There are a lot of surveys of the current state of the cloud academic purposes. This volume is published and copyrighted by its editors. Local Proceedings also appeared in ISBN 978-86-7031-200-5, Faculty of Sciences, computing market. According to the Business Web Host- University of Novi Sad. ing survey for small and midsized businesses [11] and the 30 Figure 1: Results for cloud computing concerns [11]. Figure 4: Cloud orchestration [14]. 3.1 Unified Cloud Interface/Cloud Broker The Unified Cloud Interface Project have goal to create an open and standardized cloud interface for different cloud api’s [1]. This model of unified cloud interface (cloud bro- ker) is discussed in [14]. The idea is ”to come up with an abstraction layer that is agnostic to any cloud API, plat- form or infrastructure”. The unified cloud interface (UCI) should create API for other CC APIs, to serve as common interface, to provide specification and schema for integration with other management models and exchange management information and address Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). This model suggests the usage of semantic web and OWL. The overview of the UCI Figure 2: Results for inhibition to adopt CC [4]. is shown in Figure 3. This approach is proposed by a non-profit organization Cloud Computing Interoperability Forum (CCIF). Unfortu- inaugural North Bridge, GigaOM Pro and 451 Group 2011 nately some of the biggest companies in CC have rejected Future of Cloud Computing Survey [4] one of the biggest the CCIF approach, so it is unlikely that this model will be concerns the prevents customers of adopting CC are secu- widely used. rity and interoperability. 500 customers were analyzed in the Business Web Hosting 3.2 Enterprise Cloud Orchestration Platform survey [11]. The inaugural North Bridge, GigaOM Pro and / Orchestration Layer 451 Group have provided a survey on 2011 Future of Cloud The solution InterCloud presents a federation of clouds Computing [4] by analyzing 417 participants (46% CC ven- [14]. The source of the idea is to present Internet as a net- dors and 54% non-CC vendors). The results of both of the work of networks. In this model different cloud providers can surveys about CC concerns are shown in Figures 1 and 2. register their cloud services within the orchestration layer As we can see the results are quite similar: security rep- (OL) similar to publishing the web services with the Uni- resents 20% of the answers and interoperability 13%. versal Description, Discovery and Integration (UDDI) [5]. Also both surveys predict increase of the usage of CC and [14] suggest ”The orchestration layer can then dynamically show high usage of SaaS and IaaS. select and bind to services based on criteria/algorithms that The lack of interoperability was introduced by companies determine the best cloud service for a particular job based on when they started to develop adapters in order to achieve factors like highest performance, lowest cost or other require- transfer of real applications to the cloud. Companies like ment as specified by the client”. An example of invocation CloudSwitch and RightScale already made the first step; of three different services provided by different CC provider they have developed tools to enable moving applications to is shown in Figure 4. target clouds. Beside the standard CC security issue, this model has a lot of considerations to be solved: limitation of the required 3. OVERVIEW OF CCI MODELS service platform support, dealing with delays and latencies Diferrent models have targeted different layers od the CC due to the OL performance overhead and the data volumes stack: [1] addreses all the layers of the cloud, while [5], [3] transportation overhead. and [6] target only the IaaS layer. In the following section Unfortunately this model is also not accepted by the most we will describe these models. influential CC providers. 31 Figure 3: UCI architecture [1]. 3.3 Blueprint for the Intercloud [3] discusses use cases for CCI including interoperability, inter-cloud protocols and formats for enabling the use cases. Two types of use cases are described: use cases involving a physical metaphor and use cases involving an abstract metaphor. The physical metaphor includes servers, disks, network segments, etc, and the abstract metaphor includes blob storage functions, message queue, email functions, mul- ticast functions, etc. The first type of use cases is about virtual machines (VM) instantiation and mobility. They include VM mobility trans- actions, reliable conversations between the clouds, VM trans- port and VM instantiation formats. The second type of use cases is about storage interoper- ability and federation. It includes storage subcontracting of one cloud provider with another and assumes reliable con- versation and reliable transport among clouds [3]. [3] suggests clouds of two kinds, one using hypervisors from VMware and another using open source hypervisors such as Xen and KVM from RedHat. ”Intercloud Protocols” are tested on these clouds. Figure 5 shows the architecture of Intercloud standards. A set of already established protocols are subject for further research and extension. This research only shows directions for further standard- ization and it is only a starting point. It requires a lot of future work and communication among existing CC vendors. Figure 5: Architecture for intercloud standards [3]. 32 Figure 7: Types of interoperability between appli- cations in the cloud [12]. • Interoperation among applications inside a single cloud, • Applications to exchange information and trigger op- Figure 6: Cloud service reference architecture [7]. erations across different cloud environments, • Software programs to connect multiple cloud environ- ments and to integrate data and applications across 3.4 Management Interoperability for Cloud clouds in a unified manner and Systems In 2009 the Distributed Task Management Force (DMTF) • Migration of a cloud application from one cloud envi- has formed a group dedicated to address the need for open ronment to another. management standards for cloud computing. This group is called ”Open Cloud Standards Incubator” and their aim There are no visible results in this area so far. is to develop a set of informational specifications for cloud resource management [6]. Their target is the IaaS interop- 3.6 Adapters erability. The software adapters have existed for a long time. They This group is promising since the biggest CC vendors like provide service and communication between incompatible AMD, Cisco, Citrix, EMC, HP, IBM, Intel, Microsoft, Nov- software and services; and by definition they provide inter- ell, Red Hat, Savvis, Sun Microsystems, and VMware are operability. The overall goal is the data exchange. part of this group. In the case of cloud computing adapters can provide a From 2009 till 2010 this group has created white papers new possible solution to the currently nonexistent SaaS stan- about their vision for interoperable clouds [7], architecture dards. The pool of SaaS CSP providers is growing up every for managing clouds [8] and use cases and interactions for day and there are too many software types that can be found managing clouds [9]. Since then they are working on Cloud in the cloud. It is impossible to create adapters for each type Infrastructure Management Interface (CIMI) Model and the of software. Therefore there are two possible approaches: work is still in progress. • Developing adapters for general world-wide used types This group has isolated the cloud management challenges, of software like CRM, ERP etc... created scenarios for interaction using interoperable cloud standards, defined cloud service lifecycle and created Cloud • Developing custom adapters for specific software. Service Reference Architecture [7]. Figure 6 shows the pro- posed reference architecture. Our target group is the first one. Most of the general ap- In [8] they have created more detailed definition of the plication software deal with similar data but one can expect proposed reference architecture including resource models, all this data is differently named and organized. Our goal security architecture, high-level requirements and gave pro- is to provide fast adapter production for data exchange and tocol examples. This group has also defined the manage- extraction of these data types used in common software ap- ment use cases for the lifecycle of a cloud service and the plications and to cover the four categories of interoperability data artifacts used in the use cases [9]. described by Kumar [12]. The idea is to create a general The work of Open Cloud Standards Incubator is still in data and process model that includes the most used service progress, developing slowly. They are working for almost provider in the given class of software and with the use of three years and yet they have not completed their task. And semantics to create alignment of the data. even if they do there is no guarantee that this model will be adopted by other venders that are not part of this group, 4. COMPARISON ANALYSIS OF CCI like Amazon. MODELS Table 1 presents the results of evaluation we have provided 3.5 Software and Data Interoperability in order to compare these models. The methodology consist The interoperability of the Software as a Service (SaaS) by measuring the indicators for the following categories: layer has not being analyzed as other platforms by researchers. In [12] this question is raised and initially set to the research • CC stack Layer - An indicator that tells which layer community in 2010. According to this paper SaaS CCI issue of the CC stack is addressed in the model (for example, can be summarized into four categories (shown in Figure 7): it can specify IaaS, PaaS or SaaS), 33 Table 1: Model Comparison Model CC stack Layer Details Realization Acceptance Cloud Broker IaaS Existing draft of re- Demo realization with Rejected by biggest quirements and draft Amazon EC2 and Eno- CSP OWL Ontology maly ECP Orchestration layer IaaS,PaaS,SaaS General model Early adopters: Cordys, Not accepted by biggest RightScale and CSC CSP Blueprint for the In- IaaS Only directions No No public opinion tercloud DMTF CIMI IaaS Draft documentation Expected Acceptance expected Adapters SaaS CSP API or Service re- Some existing realiza- No acceptance nedded quired tions, many possibilities • Depth - An indicator that explains the depth of de- [3] D. Bernstein, E. Ludvigson, K. Sankar, S. Diamond, scription to which the model has published the require- and M. Morrow. Blueprint for the intercloud - ments, architectures, how detailed is the model, etc protocols and formats for cloud computing . . . (for example, it can be general model specification, interoperability. In 2009 Fourth International directions only, draft documentations, etc.) Conference on Internet and Web Applications and Services, 2009. • Realization - An indicator that presents the existence [4] N. Bridge, G. Pro, and . Group. 2011 future of cloud of demo realization, or initial implementation of the computing survey results, 2011. Cloud Service Providers (CSP) or accepted and incor- [5] Cordys. Now is the time to take the cloud seriouslyy, porated by the CSP, 2011. [6] DMTF. Dmtf to develop standards for managing a • Acceptance - An indicator that shows the possibility cloud computing environment, Apr. 2009. of acceptance by the biggest Cloud Service Providers [7] DMTF. Interoperable clouds, Nov 2009. (CSP). [8] DMTF. Architecture for managing clouds, Oct. 2010. We can conclude that the only solution that can be possi- [9] DMTF. Use cases and interactions for managing bly generally used and adopted by the most of the vendors in clouds, Jun. 2010. the future is the CIMI model by DMTF providing interop- [10] P. Goyal. Enterprise usability of cloud computing erability on the IaaS level. Unlike that, the adapters don’t environments: Issues and challenges. In 19th IEEE require adoption by the vendors and are probably the only International Workshops on Enabling Technologies: possibility for near future. Infrastructures for Collaborative Enterprises, pages 54–59, 2010. [11] B. W. Hosting. Cloud computing attitudes for small 5. CONCLUSION and midsized businesses, 2011. The usage of cloud computer is increasing especially in [12] B. Kumar, J. Cheng, and L. Mcgibbney. Cloud the area of offering infrastructure and software in cloud as a computing and its implications for construction it. In Service (IaaS and SaaS). There are several approaches and W. Tizani, editor, Computing in Civil and Building research initiatives claiming progress in creation of interop- Engineering, Proceedings of the International erability in the area of IaaS. Conference, page 315. Nottingham University Press, However there is no evidence of progress for setting the 2010. interoperability in the area of SaaS. The logical steps lead [13] K. Oberle and M. Fisher. Etsi cloud - initial to creation of general interoperability frameworks for each standardization requirements for cloud services. In layer, starting from lowest, and then to expand them. At GECON’10 Proceedings of the 7th international this moment it seems unlikely for any of proposed interop- conference on Economics of grids, clouds, systems, erability model to be adopted as a standard. and services, pages 105–115. Springer-Verlag Berlin, We suggest another solution based on creation of adapters. Heidelberg, 2010. There are few dominating CC vendors on the market and all [14] A. Parameswaran and A. Chaddha. Cloud of them have created their own different solutions and can- interoperability and standardization. Technical Report not easily unite their goals in achieving the interoperability. VOL 7 NO 7, SETLabs Briefings 2009, 2009. So the next step is to start from the dominating CC mod- els and to create adapters that will ensure interoperability [15] D. Petcu. Portability and interoperability between among them. After all, we are still using electrical adapters, clouds: challenges and case study. In ServiceWave’11 when we go abroad, aren’t we? Proceedings of the 4th European conference on Towards a service-based internet, pages 105–115. Springer-Verlag Berlin, Heidelberg, 2011. 6. REFERENCES [1] Unified cloud, 2009. [2] Cloud interoperability, 2011. 34