On the Interoperability in Multiple Clouds

Dana Petcu

Computer Science Department, West University of Timis¸oara, Timis¸oara, Romania

Keywords:

Interoperability, Multiple Clouds.

Abstract:

Interoperability between Clouds is a desire of the last half decade to fulﬁll the dream of apparently unlimited

capacity of the interconnected e-infrastructures as well as the elimination of the vendor lock-in. In this paper

we try to point towards the missing pieces by identifying the requirements and the degree of their coverage by

the existing solutions. Moreover, a particular case, of application interoperability, is studied using a concrete

and recent deployable and open-source platform as a service.

1 INTRODUCTION

The need of using multiple Clouds has appear with

the proliferation of various Cloud services. The sim-

plest case, the Hybrid Cloud is motivated by the need

to deal with the peaks in e-infrastructure usage. The

migration for one Cloud to another is motivated by

economic reasons. The usage of services from a part-

ner Cloud is appealing also for the Cloud provider

in order to deal with an unexpected increase of re-

quests. Using simultaneously the services from multi-

ple Clouds (in opposition with the previous two cases

that are sequentially using different Clouds) is done

due to the particularities of each service not encoun-

tered elsewhere. Such scenarios are pushing the tech-

nical developments from nowadays and we see al-

ready several improvements of the state-of-the-art in

the last two years in what concerns the tools support-

ing the multiple Clouds usage.

In Spring 2009, OpenManifesto group

(www.openmanifesto.org) has identiﬁed the ﬁve

main challenges for the Cloud: (1) data and ap-

plication interoperability; (2) data and application

portability; (3) governance and management; (4)

metering and monitoring; (5) security. Despite the

considerable efforts in the latest four years in the ﬁeld

of Cloud computing, both in industry and research

these ﬁve challenges are still persisting. Partially

solutions or early prototypes were fortunately build

in the last two years. However, complete solutions

are not yet expected in the near future as several

technical barriers have not been overcome. In this

context, is the aim of this paper to point where the

missing pieces are. To do this, we need ﬁrst to clearly

identify the requirements and the current solutions.

Therefore the ﬁrst sections are dedicated to fulﬁll this

aim.

Interoperability is an issue for both Cloud

provider (to extend its capacity and services) as well

as for the Cloud consumer (to allow the freedom of

movement between various Clouds). In the second

part of the paper we take the position of the Cloud ap-

plication developer (whose application will consume

the Cloud services). In particular we discuss the case

of the application interoperability, having in mind that

application portability is partially solved by various

solutions.

The contributions of this paper are the followings:

1. identify the key elements of the interoperability in

multiple Cloud usage scenarios;

2. identify the current gaps in fulﬁlling the interope-

rability requirements;

3. provide a concrete example related to a recent

open-source platform as a service for multiple

Clouds, designed for portability reasons.

2 MULTIPLE CLOUDS AND

INTEROPERABILITY NEEDS

Multiple Clouds are classiﬁed nowadays (e.g. in

(Ferrer et al, 2012)) in Federated Clouds and Multi-

Clouds.

In the ﬁrst case, of Federated Clouds, agreements

or contracts between Cloud providers are established

in order to increase their services, to ensure the pos-

sibility to deal with peaks, to survive in case of dis-

581

Petcu D..

On the Interoperability in Multiple Clouds.

DOI: 10.5220/0004503105810590

In Proceedings of the 3rd International Conference on Cloud Computing and Services Science (CI-2013), pages 581-590

ISBN: 978-989-8565-52-5

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

asters. There are very few examples of such agree-

ments at this moment in the case of Horizontal Feder-

ations (between peer Clouds), and multiple in the case

of Vertical Federations (if a SaaS needs a PaaS, or a

PaaS relies on a IaaS). The reduced number of such

agreements are due to the request of a certain degree

of control by a Cloud provider over the resources or

services of another Cloud provider in agreement with

the ﬁrst. The degree of control is providing also a

criteria for further classify the Federated Clouds. Be-

yond the barrier of the agreements, the next barriers

are the technical ones, including interoperability.

The intensive studied topics for interoperability at

Federated Cloud level are related to VM migration,

API for communications and requests, automation,

standards, and so on. These subjects are related to

run-time stage of the life-cycle of services and appli-

cations: interoperability is expected to be applied dur-

ing the execution of services or applications. More-

over, interoperability is a subject for Cloud provider,

as the Cloud consumer should not be aware of the sub-

contracting.

In the second case, of Multiple Clouds, no agree-

ment needs to be established. Instead a third party

(beyond the Cloud provider and Cloud consumer) is

offering services that are build on top of the several

Cloud services, offering a unique entry point for sev-

eral Clouds. As underlined in (Grozev and Buyya,

2012) the available tools to support Multi-Clouds can

be classiﬁed in library-based or service-based. In the

case of the libraries, uniform access to infrastructure

(-as-a) services is ensured by considering the com-

mon denominator of the existing libraries. In the case

of the services, according to the applications needs, a

matching between the needs of the applications and

the special offers of various Cloud services is done

(an incipient form of a Cloud broker, not necessarily

performing auditing or single entry point, trust mea-

surements or monitoring).

The intensive studied topics for interoperability at

Multi-Cloud level are related to automation of deploy-

ments, conﬁguration of services, semantic processing

and so on. These subjects are related to design-time

stage of the life-cycle of services and applications: in-

teroperability is expected to be supported by portabil-

ity solutions. Moreover, interoperability is a subject

for the third party (representing and even identiﬁed

with the Cloud consumer).

An evolving step from the Federated Cloud or

Multi-Cloud is considered to be the Inter-Cloud,

an Federated Cloud or Multi-Cloud that includes a

Cloud broker and offers dynamic service provision-

ing. Therefore it inherits the issues already men-

tioned above in what concern interoperability at de-

sign and run-time. The Inter-Cloud goal is according

(Bernstein et al, 2009) to create an environment that

supports dynamic expansion or contraction of capa-

bilities for handling variations in demands (dynamic

workload migration is possible). A high level archi-

tecture of the Inter-Cloud was recently proposed in

(Demchenko et al, 2012).

The interaction between the Clouds can be syn-

chronous (e.g. in the case of vertical federations)

if direct calls are made, or asynchronous (in case of

loosely coupling as in emergency scenarios). The in-

teraction can be also take a synthetic form, when the

communication and exchanges are using speciﬁc for-

mats or protocols, or a semantic form, when the in-

formation exchanged is interpreted using a common

information exchange reference model.

3 INTEROPERABILITY

REQUIREMENTS

In a previous paper (Petcu, 2011) we have elaborate

on the dimensions, levels and technological require-

ments of interoperability. We remind them here and

elaborate further according to the last achievements in

the ﬁeld.

Interoperability is needed for at least for the fol-

lowing three reasons: (a) protection of the end user

investments in developments; (b) development of a

Cloud eco-system and market; (c) exploit full advan-

tage of elasticity and pay-as-you concept.

The evolution of interoperability issues has take

three stages, according (Williams, 2009): (1) migra-

tion, referring to the portability of VMs; (2) federa-

tion, targeting networking; (3) burst, targeting APIs.

Figure 1 is suggesting the three dimensions of the

interoperability problem. Two are technical and en-

countered as pointed earlier, at run-time in Federated

Clouds and at design time in Multi-Cloud. The third

dimension is non-technical, more human oriented, as

being related to policy, i.e. establishing agreements

Figure 1: Interoperability dimensions.

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

582

Figure 2: Levels of interoperability.

and contracts between providers, as well as standards

elaborations and promotion.

Figure 2 is proposing a split of the requirements

in different categories (based on the initial classiﬁca-

tion proposed in (Khattak et al, 2010)). The top level

is associated with the policy dimension; the next one

with the design; the last three with the run-time.

The most complex level is the one related to ap-

plication and services, that is covering both design

and run-time. The requirements to this level were

ﬁrst discussed in (Merzky et al, 2009), in the context

application-level interoperability versus the service-

level interoperability: the ﬁrst is considered to ensure

a strong interoperability while the second one, a weak

interoperability (note that the discussion was related

to Grids and Cloud interoperability).

Table 1 is pointing to some of the requirements of

the interoperability, associated with a certain level or

dimension as exposed in the previous ﬁgures.

4 COVERAGE AND GAPS

Several technical solutions are available currently to

support interoperability. Part of them are represented

in Figure 3 and we have review them in (Petcu, 2011).

The closest and recent snapshot of the interoperability

solution was provided in (Loutas et al, 2011). We in-

sist in this section more on gaps that should be ﬁlled,

using few examples.

For the run-time dimension, at the infrastructure

levels (last two in the table and image), several partial

solutions exists to migrate virtual machines, virtual

storage or services. Despite the presence of standard

OVF format, the VMs are not yet ready for interopera-

bility. For example, Amazon is one of the few Cloud

providers who are allowing to export VMs; however,

their related resources (e.g. network, storage) cannot

be exported too. In general, VMs cannot be trans-

ferred from one hypervisor to another. VMs can be

Figure 3: Technical solutions for interoperability.

converted today with tools like qemu-image, but this

requires to stop the VM and to apply the adaptation

off-line.

We should mention the application perspective:

also that once the application is deployed and adapted

to a certain Cloud, in order to move it in another

Cloud, an inspection of the source code is needed to

identify the speciﬁc API calls or to build a model

or representation of the code. Tools that can do

that are only in early stage of prototyping (in Euro-

pean projects like Cloud4SOA, REMICS or MODA-

Clouds) and not yet integrated in the PaaSs.

It should be also mentioned that the diversity of

the APIs is natural, as each providers intends to of-

fer something new or unique compared with other of-

fers, in order to attract customers. The interopera-

bility issue is therefore an issue for the management

and governance levels where automation should be

achieved as much as possible. The mix-in of services

from different providers can be a strong argument in

using such entry level instead a direct connection to

only one provider. Therefore the management and

service automation levels in multiple Clouds are the

hot-spots of the development activities in the last two

years (commercial solutions like RightScale, enStra-

tus or Kaavo have emerge that are able to deploy ap-

plications in various Clouds, but not yet migrate the

running ones).

For the design time dimension, several prototypes

are available, from frameworks like SLA@SOI or the

more recent (Di Modica et al, 2012), as well as APIs

like jclouds, libcloud or OpenStack (a more com-

plete list at (Lee, 2009)), or emerging standards like

CloudML, but there is no wide acceptance of one or

another proposal. Nor a Cloud speciﬁc programming

model has emerge, despite the high-potential of the

concept of e-infrastructure programming (Petcu et al,

2012b).

At the business level, a uniﬁed policy of the con-

tractual terms was not yet established at national or

international levels, while several proposals are on the

OntheInteroperabilityinMultipleClouds

583

Table 1: Minimal requirements of interoperability at various levels.

Dimension Level No Requirements

Policy Public administration P1 Regulations on contracts

P2 Regulations on services level agreements

Business B1 Business strategies

B2 Regulations on mode of use

B3 Economic model driven optimization mechanisms

B4 License ﬂexibility

Design Application/service abstractions A1 Execution-unaware application support

A2 Infrastructure independent programming

A3 Common set of interfaces, standard APIs

A4 High level modeling and programming models

Semantic S1 Message content and communication protocols

S2 Service calls and answers

S3 Cloud ontology and semantic-based discovery of services

Runtime Service automation R1 Re-conﬁguration at run-time

R2 Scaling in and out on multiple sites

R3 Workﬂow management

R4 Service and resource discovery, reservation and setup

R5 Automatically provision resources in multiple Clouds

R6 Optimal mapping of services/applications on resources

Management M1 Control the life-cycle of the application and its components

M2 Standardized functionality for deployment in multiple Clouds

M3 Migration support for application components

M4 Plug-ins for the working environment

M5 SLA and performance monitoring

M6 Standards for allocation and admission control

M7 Single sign-on for users accessing multiple Clouds

M8 Auditing and trust mechanisms

VM images, data and workloads V1 Import and share VMs, data and workloads

V2 VM, data and workloads migration support

V3 Use standards for accessing compute and storage capacities

V4 Support for multiple hypervisor technologies

Network N1 Uniform access to individual resources

N2 Routing optimization based on monitoring

N3 Software-deﬁned networking

way. One of the hottest topic is the privacy and data

protection compliance, for which no general accepted

proposal is available yet.

A classical way to bust the interoperability is the

adoption of standards and open source. Surely they

are important mostly for the Cloud providers and ser-

vice developers, not for the consumers. A classi-

ﬁcation of the standards at IaaS level was done in

(Teckelmann et al, 2011) and refers to access mecha-

nism, virtual appliance, storage, network, security and

SLA; the paper also analysis the three oldest stan-

dard proposals, OVF, OCCI and CDMI from these

point of views, identifying their gaps. Note that the

three nominated standards have partially failed to be

adopted on large scale by the providers, but are imple-

mented in few Cloud management middlewares. New

ones are emerging nowadays, like CIMI or CloudML,

and several working groups are working to elabo-

rate other proposals. Tables 2 and 3 are pointing

to some of the standards respectively standard initia-

tives that are relevant for interoperability. An ear-

lier list is provided in (Loutas et al, 2010). Com-

paring them, the tremendous changes from the last

two years are evident. However there several gaps

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

584

Table 2: Standards, reference architectures, open group proposals.

Type Standard Link Usefulness for interoperability

Standard OCCI occi-wg.org It is designed to be a management API for IaaSs allowing the

development of interoperable tools for common tasks including

deployment, autonomic scaling and monitoring. OCCI is cur-

rently evolving into a general and complex system to support

the multiple Clouds

OVF www.dmtf.org/standards/

ovf

Describes virtual appliances for deployment across heteroge-

neous virtualization platforms, like the ones using different hy-

pervisors, and allowing the users to deploy their virtual appli-

ances in various Clouds

CDMI cdmi.sniacloud.com/ Used for data management and specifying how applications

create, retrieve, update, and delete data from the cloud

CIMI dmtf.org/sites/default/

ﬁles/standards/documents/

DSP0263 1.0.1.pdf

It addresses the management of the lifecycle of Cloud infras-

tructure services. Basic resources of IaaS are modeled in order

to provide to the consumer a management access to an imple-

mentation of IaaS. It focus on the portability between cloud

implementations that support the speciﬁcation. A REST-style

protocol is proposed.

Architecture IETF tools.ietf.org/html/draft-

khasnabish-cloud-

reference-framework-01

Proposed a draft of intra-cloud and inter-cloud reference frame-

work, documenting basic functions or layers to support the gen-

eral requirements of Cloud services. The framework can be

used to standardize the interfaces between the functions/layers.

DMTF www.dmtf.org/sites/default/

ﬁles/standards/documents/

DSP-IS0102 1.0.0.pdf

Cloud Service Reference Architecture describes key compo-

nents, such as actors, interfaces, data artifacts, proﬁles and the

interrelationships among these components.

Open

groups

proposal

The

Open

group

www.opengroup.org/

getinvolved/workgroups/

cloudcomputing

The Cloud Work Group within Open group collaborate on stan-

dard models and frameworks aimed at eliminating vendor lock-

in for enterprises and looking to beneﬁt from cloud products

and services.

CSCC www.cloud-council.org Has released a guide for SLAs that highlights the critical ele-

ments of a SLA for Cloud and provides guidance on what to

expect and what to be aware of when negotiating an SLA

OCC opencloudconsortium.org Has develop benchmarks for cloud computing with a particular

focus in large data clouds: MalStone Benchmark is targeting

large data clouds

GICTF www.gictf.jp Promotes standardization of network protocols and the inter-

faces through which Cloud systems inter-work with each other.

Has published: (1) Intercloud Interface Speciﬁcation Draft

(Cloud Resource Data Model); (2) Intercloud Interface Speciﬁ-

cation Draft (Intercloud Protocol); (3) Technical Requirements

for Supporting the Intercloud Networking; (4) Use Cases and

Functional Requirements for Inter-Cloud Computing

in the collections of available standards, like propos-

als for Cloud metrics and real-time monitoring, inter-

faces for security(-as-a-)services, accountability asso-

ciated with transparency and responsibility. Further-

more, there are several barriers to the standard that

were already pointed in (Machado et al, 2009).

As the multiple Clouds are based on the values

of the Cloud services of various providers, thin lay-

ers build on top to ensure the functionality of Multi-

Cloud of Federated Cloud are often open-source. Ta-

OntheInteroperabilityinMultipleClouds

585

Table 3: Standard initiatives.

Organization Link Usefulness for interoperability

ETSI www.etsi.org/technologies-

clusters/technologies/

grid-and-cloud-

computing

Technical Committee for CLOUD is looking to interoperable solutions in-

volving IT and Telecom industries, whit emphasis on IaaS. It focuses on

interoperable applications and services based on global standards and the

validation tools to support these standards.

IEEE standards.ieee.org/develop/

project/2301.html and

2302.html

IEEE started two development projects related to cloud interoperability, re-

ﬂected in two working groups, P2301 and P2302. First group is working

on standardizing Cloud portability and management, using a number of ﬁle

formats and interfaces. The second group is focusing on Cloud-to-Cloud in-

teroperability and federation.

ITU www.itu.int/en/ITU-T/

focusgroups/cloud/Pages/

Study Group 13 works on standards for next generation networks and future

networks and in conjunction with Clouds (a Focus Group on Cloud comput-

ing has published a report).

NIST www.nist.gov/itl/cloud/ Program to develop a set of cloud computing standards. First results were

published as NIST Cloud Computing Program. NIST’ special publications

cover Cloud architectures, security, and deployment strategies for the US

federal government

OASIS www.oasis-open.org/

committees/

tc home.php?

wg abbrev=id-cloud,

www.oasis-open.org/

news/announcements/

symptoms-automation

-framework-saf-v1-0

-cs02-published,

docs.oasis-open.org/

tosca/TOSCA/v1.0/

TOSCA-v1.0.html

Three cloud speciﬁc or extended technical committees have been founded:

(1) Identity in the Cloud, looking to the security challenges posed by identity

management in Cloud, identifying the gaps in current identity management

standards, and investigating the need for proﬁles to achieve interoperability

within current standards; (2) Symptoms Automation Framework, facilitating

knowledge sharing and allowing consumer and provider to work coopera-

tively together to ensure adequate capacity, maximize quality of service, and

reduce cost; (3) Topology and Orchestration Speciﬁcation for Cloud Appli-

cations looking to enhance the portability of Cloud applications and services,

and enabling the interoperable description of application and infrastructure

Cloud services, the relationships between parts of the service, and the opera-

tional behavior of these services.

SNIA www.snia.org/

tech activities/

work/twgs

Cloud Storage Technical Work Group is developing an architecture related to

system implementations of cloud storage technology

Fo-

rum

www.tmforum.org/

DigitalServices/13907/

home.html

Cloud Services Initiative intends to stimulate the growth of an open mar-

ketplace for Cloud services by promoting to large eco-system of enterprise

customers, Cloud and technology providers the adoption of standards

ble 4 is pointing to the recent open-source solutions

that are supporting multiple Clouds.

5 EXAMPLE

We consider in this section an example: how one

of the latest open-source middleware for multiple

Clouds is supporting the interoperability. We have

pick mOSAIC, as being recent contributor to it. mO-

SAIC is providing an open-source and deployable

Platform-as-a-Service that is supporting multi-Cloud

scenario of re-deployment. The initial cycle of its de-

velopment was supported through a collaborative and

multi-national project, funded by the European Com-

mission and ended in Spring 2013. Targeting open-

source, its codes are available at the public repository

https://bitbucket.org/mosaic, under Apache License.

Figure 4 indicates the main components of the lat-

est stack of mOSAIC’s software:

– red components, for the design phase: API li-

braries (for Java, Python and Erlang) with ex-

amples; application tools including plug-ins for

Eclipse, templates and workﬂows; semantic sup-

port for developing applications, using domain

speciﬁc and Cloud ontologies; a service-level

agreement framework based on concepts intro-

duced by SLA@SOI;

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

586

Table 4: Open-source middleware, framework, library, tool or service that is working with multiple Clouds and support a

certain degree of interoperability.

Acronym Link Short description

Aoleus www.aeolusproject.org Cloud management software sponsored written in Ruby, open source,

and provided by Red Hat on Linux systems. It allows users to choose

between private, public or hybrid clouds, using δ-Cloud library

BonFIRE portal.integration.

bonﬁre.grid5000.fr/

Operates a Multi-site Cloud-based facility on top of infrastructure

testbeds. Its Enactor shields the implementation details of how to in-

teract with various testbeds from a resource manager.

ConPaaS contrail-

project.eu/conpaas

Provides a federation layer support for bringing Cloud providers to-

gether. It allows Cloud bursting. The Contrail Virtual Execution Plat-

form interfaces with the IaaS layer of Cloud providers and upgrades the

supported Cloud providers by adding SLAs features

δ-Cloud deltacloud.apache.org It is REST-based API written in Ruby necessary to connect to various

Cloud providers (Amazon EC2, Eucalytus, SmartCloud, GoGrid, Open-

Nebula, RackSpace, OpenStack and others)

JClouds www.jclouds.org It is an open source Java library that introduces abstractions aim-

ing the portability of applications. It support more than thirty Cloud

providers and software stacks including AWS, GoGrid, vCloud, Open-

Stack, Azure.

LibCloud libcloud.apache.org Apache Libcloud is a standard Python library that abstracts away differ-

ences among multiple Cloud provider APIs

mOSAIC bitbucket.org/mosaic An API and a deployable PaaS that allows deployment, conﬁguration

management, and control of the life-cycle of applications or services

consuming IaaS. Supports more than ten providers

Nimbus www.nimbusproject.org Introduces a virtual site layer for dynamically provisioned distributed

resources of multiple data centers and a closed federation model where

resources are shared based on cooperation

OPTIMIS www.optimis-project

.eu/Toolkit v2

Is a platform for Cloud service provisioning that manages the lifecycle

of the service and addresses issues like risk and trust management

SAGA saga-project.github.com API for managing e-infrastructures, from Grids to Clouds. Implemen-

tation of MapReduce using SAGA is proving its support for interopera-

bility across Clouds and Grids.

SimpleCloud www.simplecloud.org It is a PHP library providing common interfaces for ﬁle and document

storage services, queue services and infrastructure services

StratusLab stratuslab.eu It is an open source IaaS distribution that can be used for Cloud bursting

– green components, for the deployment phase: the

brokerage system including the Cloud Agency

that assists in the selection of the Cloud provider

according to the application needs speciﬁed in a

particular descriptor and generating the service

level agreement, as well as vendor agents;

– blue components, for the runtime phase: support

for a Personal Cloud (on a desktop using the

Portable Testbed Cluster), for provider resource

allocation based on existing credentials, the min-

imal kernel of the platform (mOS) to run re-

motely on providers’ virtual machines, a naming

service that offers an application virtual domain,

and the execution engine that allows the control

of the deployed applications; customized versions

of open source Cloud technologies (for message

queues, key value stores, distributed ﬁle systems)

are available to be deployed (COTS) with corre-

sponding drivers; special web-interfaces and con-

sole interfaces are allowing the control of the ap-

plication life-cycle at the level of their compo-

nents; benckmark sets are supporting the testing

of applications and infrastructure services;

– purple components, the proof-of-the-concept appli-

cations.

Drivers and vendor agents are currently available

OntheInteroperabilityinMultipleClouds

587

Figure 4: mOSAIC’s software package: main components.

for various Public Cloud providers (Amazon, Flexi-

ant, CloudSigma, GoGrid, OnApp, NIIFI) as well

as for Private Cloud support technologies (Eucalyp-

tus, OpenNebula, VMware, DeltaCloud, OpenStack,

CloudStack).

mOSAIC is targeting mainly Cloud-enabled ap-

plication portability – details can be found in (Petcu

et al, 2012a; Sandru et al, 2012). The targeted ap-

plications are based on loosely coupled components

that can be written in different languages and which

are can be elastic (can be multiplied or reduced in the

number of instances, at run-time).

The interoperability in multiple Cloud scenarios

is only partially supported by mOSAIC, and is the

aim of this section to detect the degree of coverage

of the interoperability requirements as identiﬁed in

the previous section. Table 5 is presenting the result

of the analysis. Most of the requirements enumer-

ated in the previous section (more than three quar-

ters) are fulﬁlled. Not accidentally the PaaS is not

able to offer solutions to several problems: auditing

or trust mechanisms, optimized or inter-Cloud rout-

ing, sharing data between Clouds. These are subject

of complex prototype platforms or intensive studies of

other teams and projects (like TClouds for trust mech-

anisms).

Targeting to support the developers, less the

providers, mOSAIC is oriented more towards inter-

operability solutions at design phase (application in-

teroperability) and part of the run-time requirements

related to the infrastructure (e.g. VMs and data migra-

tions, or routing) are not yet served. However this sta-

tus can be changed in the future in the further devel-

opment stages, including the current on in the frame

of MODAClouds project, in which support for migra-

tion of services and data is expected to be added (as

well as support for the emerging standard CloudML).

Developed based on a strategy established three

years ago, mOSAIC has not take advantage of the new

standardization initiatives, incorporating only those

that were available at its development moment. A re-

factoring of its codes as well as of the other close re-

lated platforms or resource management tools accord-

ing to the new emerging standards speciﬁcations can

raise the interest of the application developer commu-

nity.

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

588

Table 5: mOSAIC support for interoperability on the technical dimensions (design and run-time)

No Requirement Support

A1 Execution-unaware application support At the development phase the code is independent from the

speciﬁc Cloud APIs; at the deployment phase the platform is

entitled to use drivers to match various APIs of the selected

Cloud provider

A2 Infrastructure independent programming At the development phase, the code does not include any

VM reference; the operations on the storage are referring

only to a general type (e.g. key-value store)

A3 Common set of interfaces, standard APIs Resources of same type have one interface in development

stage

A4 High level modeling and programming models Templates are used

S1 Message content and communication protocols Asynchronous interaction, based on message queues, a stan-

dard protocol (AMQP) is used for communications

S2 Service calls and answers In the case services are translated into the platform speciﬁc

messages that are transmitted via message queues

S3 Cloud ontology and semantic-based discovery

of services

A Cloud ontology has been build and new Cloud services

can be detected and aligned

R1 Re-conﬁguration at run-time According to the behavior of the components, they can be

multiplied/stopped during the execution

R2 Scaling in and out on multiple sites Scaling is done by the platform at one deployment site (no

cross-Cloud border mechanisms)

R3 Workﬂow management Start the application components in a certain order

R4 Service and resource discovery, reservation and

setup

A service discovery mechanism has been designed, the re-

sources are conﬁgured automatically by the drivers

R5 Automatically provision services in multiple

Clouds

The provisioning is done in the same way for various Cloud

providers

R6 Optimal mapping of services/applications on

resources

Cost optimality is targeted by the brokerage system

M1 Control the life-cycle of the application and its

components

The application components can be started, stopped, multi-

plied during the application execution

M2 Standardized functionality for deployment in

multiple Clouds

The deployment is done by a particular component of the

platform, that is not Cloud dependent

M3 Migration support for application components The components needs to be stopped and started remotely

M4 Plug-ins for the working environment Eclipse plug-ins are available

M5 SLA and performance monitoring An SLA framework was build, that is involving SLA bro-

kerage and monitoring

M6 Standards for allocation and admission control Use standards to logging

M7 Single sign-on for users accessing multiple

Clouds

A credential service has been build to facilitate the user ac-

cess to various Clouds (however it does not ensure single

sign-in)

M8 Auditing and trust mechanisms No support for auditing or trust mechanisms

V1 Import and share VMs, data and workloads A special image at Cloud providers with the platform is

available. No support for sharing workloads or data

V2 VM, data and workloads migration support No support for migration

V3 Use standards for accessing compute and

storage capacities

OCCI can be used in the brokerage and the resource control

V4 Support for multiple hypervisor technologies The platform was tested on three hypervisors (no modiﬁca-

tion needed)

N1 Uniform access to individual resources From the programming point of view, similar resources are

addressed in the same way, only the types (e.g. key-value

store, distributed ﬁle system, message queues) are different

N2 Routing optimization based on monitoring No special support for routing optimization

N3 Software-deﬁned networking No special support for inter-Cloud routing

OntheInteroperabilityinMultipleClouds

589

6 CONCLUSIONS

Interoperability in multiple Clouds is still an open

problem. Considerable improvements where done in

the last two years. However the subject is far from

being closed. We have try to provide in this paper

a snapshot of the state-of-the-art. A spot light was

put on the current gaps in ensuring interoperability

through technical solutions. Moreover, we proposed

a list of technical requirements of the interoperability

and in order to check the list we have pick one exam-

ple of a current open-source and deployable platform-

as-a-service for multiple Clouds.

ACKNOWLEDGEMENTS

This work was supported by the grant of Romanian

National Authority for Scientiﬁc Research, CNCS

UEFISCDI, PN-II-ID-PCE-2011-3-0260 (AMICAS).

REFERENCES

Bernstein, D., Ludvigson, E., Sankar, K., Diamond, S.,

Morrow, M.: Blueprint for the Intercloud - proto-

cols and formats for cloud computing interoperabi-

lity. Procs. ICIW ’09, IEEE Computer Press, 328–336

(2009)

Demchenko, Y., Makkes, M.X., Strijkers, R., de Laat, C.:

Intercloud Architecture for interoperability and inte-

gration. Procs. CloudCom ’12, IEEE Computer Press,

666-674 (2012)

Ferrer, A.J. et al, OPTIMIS: A holistic approach to cloud

service provisioning, Future Generation Computer

Systems 28, 66–77 (2012)

Grozev, N., Buyya, R.. Inter-Cloud Architectures and Ap-

plication Brokering: Taxonomy and Survey. Soft-

ware Practice and Experience, doi: 10.1002/spe.2168

(2012)

Khattak, A.M., Pervez, Z., Sarkar, A.M.J. Lee, Y.-K.:

Service level semantic interoperability. Procs. IEEE

SAINT 2010, IEEE CSP, 387–390 (2010)

Lee, C.A., An open cloud computing interface status up-

date (and roadmap dartboard) Cloud interoperability

roadmaps sessions, OMG Technical meeting (2009)

Loutas, N., Peristeras, V., Bouras, T., Kamateri, E., Zeginis,

D., Tarabanis, K.: Towards a reference architecture for

semantically interoperable clouds. Procs. CloudCom

2010, IEEE CSP, 143–150 (2010)

Loutas, N., Kamateri, E., Bosi, F., Tarabanis, K.: Cloud

Computing Interoperability: The State of Play. Procs.

CloudCom 2011, IEEE CSP, 752–757 (2011)

Machado, G.S., Hausheer, D., Stiller, B.: Considerations on

the interoperability of and between cloud computing

standards. Procs. OGF27: G2C-Net (2009)

Merzky, A., Stamou, K., Jha, S.: Application level interope-

rability between clouds and grids. Procs. GPC work-

shops 2009, IEEE CSP, 143–150 (2009)

Di Modica, G., Petralia, G.;, Tomarchio, O.: A Semantic

Framework to Support Cloud Markets in Interopera-

ble Scenarios. Procs. UCC 2012, IEEE CSP, 211–214

(2012)

Petcu, D.: Portability and Interoperability between Clouds:

Challenges and Case Study. Procs. ServiceWave 2011,

LNCS 6994, 62–74 (2011)

Petcu, D., Macariu, G., Panica, S., Craciun, C.:

Portable Cloud Applications - from Theory to

Practice, Future Generation Computer Systems,

doi:10.1016/j.future.2012.01.009 (2012)

Petcu, D., Frincu, M.E., Panica, S., Neagul M.: Towards

Programmatic Management of Services from Multiple

Clouds. Procs. InCoS 2012, 487–488 (2012)

Sandru C., Petcu, D., Munteanu, V.: Building an Open-

source Platform-as-a-Service with Intelligent Man-

agement of Multiple Cloud Resources. Procs. UCC

2012, 333-338 (2012)

Teckelmann, R., Reich, C., Sulistio, A.: Mapping of Cloud

Standards to the Taxonomy of Interoperability in IaaS.

Procs. CloudCom 2011, 522–526 (2011)

Williams, J.L.: An implementor’s perspective on interoper-

able cloud APIs. Cloud interoperability roadmaps ses-

sions, OMG Technical meeting (2009)

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

590