Provisioning of Component-based Applications Across Multiple Clouds

Mehdi Ahmed-Nacer

1,2

, Sami Yangui

, Samir Tata

2,4

and Roch H. Glitho

University of Sciences and Technology Houari Boumediene, Algiers, Algeria

SAMOVAR, Telecom SudParis, CNRS, Universite Paris-Saclay, 9, rue Charles Fourier, 91011 Evry Cedex, France

Concordia Institute for Information Systems Engineering, Concordia University, Montreal, QC, H3G 2W1, Canada

IBM Research-Almaden, San Jose, CA, 95120, U.S.A.

Keywords:

Cloud Computing, COAPS, OCCI, PaaS, Resource Provisioning.

Abstract:

The several existing Platform-as-a-Service (PaaS) solutions are providing application developers with differ-

ent and various offers in terms of functional properties (e.g. storage), as well as, non-functional properties (e.g.

cost, security). Consequently, developers may need to provision components of the same application across

several PaaS depending on their related requirements and/or PaaS capabilities. This paper proposes generic

mechanisms that allow seamless component-based applications provisioning across several PaaS. These mech-

anisms are based on the COAPS API; an already deﬁned OCCI-compliant API that allows provisioning of

monolithic applications in PaaS using generic descriptors and operations. To illustrate the proposed mecha-

nisms, the paper showcases a realistic use case of provisioning of a JEE-based simulation application across

Elastic Beanstalk and Cloud Foundry platforms.

1 INTRODUCTION

Cloud computing is an emerging model for enabling

ubiquitous, convenient, and on-demand network ac-

cess to a shared pool of conﬁgurable computing re-

sources (Mell and Grance, 2009). Cloud comput-

ing providers offer their services according to three

different models, namely Infrastructure as-a-Service

(IaaS), Platform as-a-Service (PaaS), and Software

as-a-Service (SaaS). According to these three ser-

vice models, Cloud resources should be swiftly pro-

visioned with minimal management effort.

The completion and the achievement of such

model have induced the proliferation of not only

cloud end-users but cloud service providers as

well (Dash et al., 2009). The agreements be-

tween both sides are based on the pay-as-you-go

model (Grossman, 2009). Generally, cloud providers

(e.g. IaaS, PaaS) vary their offers in terms of func-

tional properties (e.g. storage, networking), as well

as, non-functional properties (e.g. cost, security) in

order to attract as many clients as possible. Conse-

quently, end-users are facing real challenges in order

to fully optimize their cloud usage while meeting their

functional and non-functional requirements. This in-

evitably involves the need of multi-provider provi-

sioning of the handled resources, since probably none

of the involved cloud providers will be able to pro-

vide the entire required services, with respect to all

end-user requirements.

Provisioning cloud resources cover describing,

deploying and managing them (Yangui and Tata,

2016). For instance, for cloud end-user applications

case, the related provisioning process consists of: (1)

Describing the application requirements, (2) allocat-

ing PaaS resources necessary to meet such require-

ments, (3) deploying the application over these re-

sources and (4) managing (including executing) it.

However, when considering such context, many lim-

itations and issues still persist in order to be able to

provision applications across several PaaS. These is-

sues are mainly due to the diversiﬁcation of the PaaS

solutions and the strong heterogeneity of their pro-

vided resources, services, APIs, etc. In fact, existing

PaaS solutions (e.g. Google Cloud Platform

, Cloud

Foundy

, Heroku

) propose heterogeneous frame-

works and runtimes for applications depending on

their implementation technologies and capabilities. In

addition, these frameworks are provisioned by PaaS

in a speciﬁc way. Each PaaS has its own deployment

cloud.google.com

cloudfoundry.org

heroku.com

104

Ahmed-Nacer, M., Yangui, S., Tata, S. and Glitho, R.

Provisioning of Component-based Applications Across Multiple Clouds.

DOI: 10.5220/0006296901320142

In Proceedings of the 7th International Conference on Cloud Computing and Services Science (CLOSER 2017), pages 104-114

ISBN: 978-989-758-243-1

Figure 1: JEE-based simulation application deployment across several PaaS.

scenario and procedures. Consequently, these speci-

ﬁcities and limitations make difﬁcult provisioning of

component-based applications, such as applications

described according to Service-Oriented Architecture

(SOA) speciﬁcations, in a multi-PaaS environment.

To address these issues, this paper proposes

generic mechanisms that allow seamless component-

based applications provisioning across several PaaS.

These mechanisms enable the placement of applica-

tions’ components into several PaaS in order to fully

take advantage of their various offers when deploy-

ing and managing them. This provisioning is per-

formed using the same operations and descriptors.

The proposed solution uses and extends Compati-

bleOne Application Provisioning Service

(COAPS

for short). COAPS provides uniﬁed description model

and API that allows provisioning applications in a

given PaaS (Yangui and Tata, 2016) (Sellami et al.,

2013b). It is based on the Open Cloud Comput-

ing Interface (OCCI) recommendation for a stan-

dard (OCCI, 2016). A prototype was implemented

in order to validate these ﬁndings.

The rest of the paper is organized as follows: Sec-

tion 2 introduces a motivating use case. Section 3

presents the already existing COAPS API. Section 4

presents M-COAPS, the proposed extension for en-

abling generic multi-PaaS applications provisioning.

Section 5 describes the implementation details and the

developed prototype for its validation. Section 6 eval-

uates the existing related work. Section 7 concludes

the paper and discusses the planned future works.

2 USE CASE AND MOTIVATIONS

Let us consider the provisioning of the JEE-based

simulation application across several PaaS as use

case. This application is shown in Figure 1. It allows

compatibleone.com/cgi-sys/suspendedpage.cgi#coaps

simulating the operation of applications in cloud envi-

ronments based on a given conﬁguration provided by

the user. The user provides a description of the appli-

cation and the conﬁguration of the cloud environment

to simulate. Each conﬁguration describes a prospec-

tive hosting cloud environment in terms of required

datacenters, VMs, applications instances and so on.

The simulation application is designed according to

the MODEL-VIEW-CONTROLLER pattern. It con-

sists of three components:

• The Front-end component provides a set of

graphic Web interfaces that allow users to deﬁne

and/or edit a simulation conﬁguration template

(Figure 1, action 1). A snapshot of such interface

is shown in Figure 2. Speciﬁcally, a user has two

options: (1) Deﬁne a new conﬁguration and run

its simulation or (2) display an existing conﬁgu-

ration with its already calculated simulation data.

This component refers to as the VIEW entity.

• The Recorder component allows the storing of a

newly deﬁned simulation template in a persistent

database for reuse purposes (Figure 1, action 2). It

also allows uploading and sending stored conﬁgu-

rations, and eventually their related simulation re-

sults, to the Front-end component for display. The

used database schema is No-SQL key-value. This

component refers to as the MODEL entity.

• The Simulator component is based on CloudSim

an open-source cloud simulation tool. It simu-

lates and evaluates cloud applications character-

istics (e.g. performance) for a given set of con-

ﬁguration templates. The simulation result is sent

to the Front-end component for display (Figure 1,

action 3) and to the Recorder component for stor-

age (Figure 1, action 4). This component refers to

as the CONTROLLER entity.

On one side, developers may have to deploy

and/or manage such application across several PaaS.

cloudbus.org/cloudsim/

Provisioning of Component-based Applications Across Multiple Clouds

105

Figure 2: The conﬁguration templates management interface.

A multi-PaaS provisioning could be motivated by sev-

eral reasons such as security, cost and/or performance.

For example, for cost point of view, a basic compute

node (i.e. Linux OS, 1 core CPU, 128 GB of RAM

and 1Go of storage disk) costs $0.006/Hour in Cloud

Foundry while it costs $0.013/Hour in Amazon EC2.

In addition, the average cost of 1GB of basic key-

value storage service is $71/Month in Cloud Foundry

(RedisDB service) while it is $43/Month in Ama-

zon (DynamoDB service). Therefore, based on these

rates, developers might be interested by the alternative

of provisioning the application’s components that re-

quire intensive compute resources in Cloud Foundry

rather than Amazon (Figure 1, action B). In the same

way, they may consider provisioning components that

handle data storage in Amazon rather than Cloud

Foundry (Figure 1, action C). Finally, it should be

noted that the GUIs could be provisioned locally in

the end-users terminals for cost optimization and per-

formance purposes (Figure 1, action A). This is very

common practice for components that are part of the

VIEW entity in applications designed according to the

MODEL-VIEW-CONTROLLER pattern.

On the other side, runtimes, frameworks and host-

ing cloud resources are provisioned by existing PaaS

in speciﬁc way. This makes the aggregation and the

automation of multi-PaaS provisioning difﬁcult to set.

Each PaaS solution has proprietary model to describe

and provision applications and their related hosting

resources. Furthermore, the user APIs implement-

ing these description models are strongly heteroge-

neous (e.g. proprietary operations, speciﬁc provision-

ing scenarios, etc.). These limitations are forcing de-

velopers to adapt their applications and procedures

when they deploy and manage component-based ap-

plications across several PaaS in order to bypass the

vendor lock-in (Satzger et al., 2013).

To address these issues, a couple of requirements

need to be met. The ﬁrst requirement is the need for

mechanisms that enable and automate provisioning

of component-based applications across several PaaS.

This will allow taking beneﬁt from the variety of the

PaaS offerings. It also provides the developers with

more alternatives to satisfy their needs and optimize

their applications operating. The second requirement

is the need for a uniﬁed model and generic provision-

ing mechanisms. PaaS-independent mechanisms will

considerably harmonize and simplify the provisioning

procedures of applications’ components across sev-

eral PaaS.

COAPS meets the latter requirement related to the

need for uniﬁed model and generic operations. In-

deed, as part of a previous work, COAPS was de-

signed and implemented as PaaS-independent solu-

tion that provides a set of generic REST interfaces.

These interfaces aggregate the APIs exposed by the

PaaS offerings based on a uniﬁed resources descrip-

tion model (Sellami et al., 2013b) (Yangui et al.,

2014). However, it should be noted that COAPS only

supports the provisioning of monolithic applications.

Furthermore, it does not support any multi-PaaS pro-

visioning approach. Indeed, developers cannot use

COAPS to deploy applications on top of more than

one PaaS offering. Consequently, COAPS does not

meet the ﬁrst requirement.

In this paper, an extended COAPS solution that

meets the ﬁrst identiﬁed requirement related to the

automation of applications provisioning across sev-

eral PaaS is proposed. For understanding, COAPS

is ﬁrstly introduced in Section 3. Then, Multi-PaaS

COAPS solution (M-COAPS for short) is discussed

in Section 4.

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

106

3 COMPATIBLEONE

APPLICATION PROVISIONING

SERVICE

COAPS is a PaaS-independent model and API for

PaaS resources provisioning. The introduced model

is based on the Open Cloud Computing Interface

(OCCI) speciﬁcations. It enables the description

of both platform and application resources indepen-

dently of the target PaaS.

OCCI is a set of speciﬁcations that deﬁne a meta-

model for abstract cloud resources and a RESTful

protocol for their management (OCCI, 2016). It of-

fers a ﬂexible API with a strong focus on interoper-

ability while still offering a high degree of extensi-

bility. COAPS model consists of: (1) An OCCI plat-

form speciﬁcation which describes all PaaS resources

that can be provisioned by a PaaS to set up an ap-

propriate hosting-environment (Yangui et al., 2013)

and (2) an OCCI application speciﬁcation which de-

scribes the application resources to deploy in this

environment (Sellami et al., 2013a). Indeed, the

main resources handled by this model are Environ-

ment and Application. Environment resources are

composed of platform resources (e.g. containers,

databases). Application resources involve all neces-

sary artifacts required to execute the application once

it is deployed (e.g. source code, conﬁguration ﬁles,

scripts). Each one of the deﬁned resources is char-

acterized by a set of attributes and actions to handle

and manage them according to OCCI speciﬁcations.

The detailed list of these resources and their related

attributes and actions are discussed in (Yangui and

Tata, 2016).

COAPS API provides end-users with a set of

generic operations for applications provisioning.

These operations implement the actions that can be

applied to platform and application resources accord-

ing to the deﬁned description model. COAPS API

is based on OCCI HTTP Renderings (Metsch and

Edmonds, 2011) and Representational State Transfer

(REST) architecture. The listing of COAPS abstract

generic interfaces and related speciﬁcations are de-

tailed in (Sellami et al., 2013b). COAPS is designed

according to a proxy system that allows implementing

and adapting its abstract interfaces when integrating a

new PaaS offering.

As shown in Figure 3, COAPS proxy architecture

consists of three layers:

• Front-end layer, that exposes the COAPS generic

interfaces. These interfaces represent abstract

RESTful operations for application and related

hosting-environment provisioning;

Figure 3: COAPS proxy system.

• Back-end layer, that represents the PaaS offerings

interfaces. These interfaces expose the propri-

etary API operations of a given PaaS;

• Mapping-end layer, that constitutes the middle

layer of the proxy. This layer ensures the map-

ping between the COAPS generic operations on

one side and the proprietary PaaS API operations

on the other side.

To create a new COAPS implementation for a

given PaaS offering, one can simply instantiate its

proxy after implementing its correspondent middle

layer to map between the COAPS generic interfaces

and the proprietary operations exposed by the API

of the selected PaaS. Currently, proxies for Cloud

Foundry, OpenShift, Elastic BeansTalk and Google

App Engine platforms are implemented (available

at (coa, 2016)). However, COAPS does not allow us-

ing more than one proxy at the same time to deploy

one application across multiple PaaS.

4 M-COAPS FOR MULTI-PAAS

PROVISIONING

The M-COAPS (M stands for Multi-PaaS) solution

discussed in this section aims at meeting the require-

ment related to automatic applications provisioning

across several PaaS. It addresses the identiﬁed limita-

tions and drawbacks of COAPS described at the end

of Section 3. M-COAPS supports component-based

applications provisioning. This includes applications’

components deployment and management in the sev-

eral involved PaaS offerings. The decision to place

the applications’ components in the available PaaS of-

ferings could be motivated by criteria such as hosting

cost, applications’ components requirements and/or

hosting PaaS capabilities. While the issues related to

the decision on components placement are important,

the contributions discussed in this paper i.e. the effec-

tive deployment across multiple platforms are com-

plex enough in themselves to deserve separate treat-

ment. Placement decisions are out of the scope of this

Provisioning of Component-based Applications Across Multiple Clouds

107

Figure 4: M-COAPS provisioning process.

paper.

As it is the case for COAPS, M-COAPS pro-

vides generic interfaces in order to allow deploying

and managing components of the same application

in different PaaS offerings. The provisioning steps

are performed following the process shown in Fig-

ure 4. Broadly speaking, a developer ﬁrst creates the

required hosting environments resources for its appli-

cation’s components in the target platforms. Then,

he/she creates the resources representing the applica-

tion’s components. After that, he/she proceeds to the

concrete deployment and the activation of the whole

application. Detailed description of each activity of

the provisioning process is provided in the rest of this

section.

4.1 createEnvironment Operation

createEnvironment operation instantiates an Envi-

ronment resource and allows allocation of the re-

quired platform resources for hosting and executing

an application (e.g. containers, DBMS). This opera-

tion is executed as many times as there are hosting-

environments to provision. Each created Environ-

ment belongs to a given PaaS offering. The properties

of each Environment, as well as, its target PaaS are

described in a descriptor provided by the developer

when calling this operation.

4.2 createAppComponent Operation

createAppComponent operation instantiates the re-

quired ApplicationComponent resources, that made

up a component-based application. This operation is

executed as many times as the number of components

of the application to deploy. The components’ prop-

erties (e.g. name, code version, and artifacts location)

are listed in the application descriptor provided by the

developer. The components listing order in the de-

scriptor has meaning. It deﬁnes the ﬂow and indi-

cates the order of executing the several component in

order to implement the ﬁnal application’s functional-

ity (business logic). In addition, the developer have

to mention in the descriptor to which already created

Environment each ApplicationComponent belongs. It

should be noted that the same Environment can be as-

signed to several applications’ components if needed.

4.3 deployApplication Operation

deployApplication operation allows uploading the

application’s artifacts over the hosting Environment

for the concrete deployment. It enables orchestrat-

ing the deployment of the several application’s com-

ponents. Speciﬁcally, it deploys the created Applica-

tionComponent resources over their related Environ-

ment in the target PaaS offerings. The orchestration

consists on processing the wiring of the application’s

components once they are deployed. It follows the re-

verse of the application execution chain mentioned in

its descriptor. Basically, deployApplication starts

by processing ApplicationComponent N. It uploads its

source code on the target PaaS, ﬁnalize the deploy-

ment and collects its associated public access URL

returned by the hosting PaaS. Then, it provides this

URL to ApplicationComponent N-1 when process-

ing its deployment until reaching the front-end com-

ponent. The location of ApplicationComponent N

is provided to ApplicationComponent N-1 through a

routing ﬁle attached to the application’s component

code at upload time.

4.4 startApplication Operation

startApplication operation allows activating the

whole deployed application’s components. An appli-

cation is considered as available when all its related

components are activated. The starting process or-

der follows the same order of the application execu-

tion chain. It begins by starting the front-end compo-

nent. Then, it starts the next component in the exe-

cution chain until reaching ApplicationComponent N.

It should be noted that the same order is followed for

stopApplication and restartApplication oper-

ations as well.

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

108

Figure 5: M-COAPS Web client.

5 IMPLEMENTATION AND

VALIDATION

M-COAPS is implemented according to the speciﬁca-

tion and the provisioning process shown in Figure 4.

It is developed as HTTP RESTful Web application

with Java (JAX-RS) using Jersey. The descriptors are

XML-based. Currently, the Cloud Foundry and Ama-

zon Elastic Beanstalk proxies are integrated to M-

COAPS. Adding new proxy support is done according

to the RESTful architecture principles. In addition to

that, the already performed COAPS Web client was

adapted in order to be in-line with the new M-COAPS

capabilities as it is shown in Figure 5. The client’s

interface allows henceforth several artifacts uploads

from different locations. Each artifact corresponds

to a speciﬁc application’s component. Similarly, the

resources path ﬁeld allows henceforth specifying a

list of Environment and ApplicationComponent re-

sources IDs. In order to validate the implementation,

the provisioning of the JEE-based simulation appli-

cation introduced in Section 2 was performed using

M-COAPS across Cloud Foundry and Amazon Elas-

tic Beanstalk. The associated descriptors are shown

in Listing 1. The source code of this implementation

and a demonstration video showing the execution of

the different steps are available at COAPS API Web-

page (coa, 2016). According to the scenario discussed

in Section 2, the Simulator component is provisioned

in Cloud Foundry while the Recorder component is

provisioned in Amazon Elastic Beanstalk. The details

of the provisioning of this application are described in

the rest of this section according to the provisioning

process steps shown in Figure 4. The parallel opera-

tions are implemented as java threads for performance

purpose.

5.1 createEnvironment Operation

This step allows the creation of the required Envi-

ronment resources and the instantiation of these re-

sources on the two target PaaS. createEnvironment

is a POST REST request. It returns back a set of

EnvIDs related to the newly created Environment re-

sources. The XML elements describing Environment

resources properties are shown in Listing 1 (lines 6-

18).

SimEnv is the ﬁrst hosting environment to create

(lines 6-11). The target PaaS (i.e. Cloud Foundry)

is indicated as value of provider attribute (line 6).

The associated description is provided in line 8. This

environment consists of a single PaaS resource node

i.e. an Apache Tomcat Web container (line 9). Stor-

ageEnv is the second hosting environment to create

(lines 12-18). The target provider is Amazon Elastic

Beanstalk (line 12). The environment description is

provided in line 14. This environment consists of two

nodes: An Apache Tomcat Web container (line 15)

and a DynamoDB database service (line 16).

It should be noted that for reuse purpose, it is

possible to deﬁne environment templates and simply

refer to the template name in the descriptor during

future environment creations. For instance, SimEn-

vTemp is associated SimEnv template (lines 7-10)

while StorageEnvTemp is associated to StorageEnv

template (lines 13-17).

5.2 createAppComponent Operation

This step allows the creation of the re-

quired ApplicationComponent resources.

createApplicationComponent is a POST REST

request. It returns back a set of AppIDs related to the

newly created ApplicationComponent resources. The

XML elements describing ApplicationComponent

resources properties are shown in Listing 1 (lines 19-

33). Simulator is the name of the ﬁrst component to

create (lines 19-26). The hosting environment of this

component is SimEnv (line 19). Consequently, it will

be provisioned in Cloud Foundry. The description of

this component is provided in line 20. Its associated

artifacts name and location are provided in line

22. During the deployment of this component, the

target PaaS has to instantiate and run two instances

of it (lines 23-24). The main instance is Instance1

(default instance=”true”). The two instances has

to be started simultaneously (initial state=”1”).

The second component to create is Recorder (lines

27-33). Its hosting environment is StorageEnv (line

27). This component will be provisioned in Amazon

Elastic Beanstalk. Its description is provided in line

Provisioning of Component-based Applications Across Multiple Clouds

109

1 <?xml version="1.0" encoding="UTF-8"?>

2 <paas_application_manifest name="SimulationApplicationManifest">

3 <description>This_manifest_describes_the_SimulationApplication_Environments_and_Components</description>

4 <paas_application name="SimulationApplication">

5 <description>This_App_simulates_deployment_costs_of_given_configs<description>

6 <paas_environment name="SimEnv" provider="CF" template="SimEnvTemp">

7 <paas_environment_template name="SimEnvTemp" memory="512">

8 <description>SimulatorHostingEnvironmentTemplate</description>

9 <paas_environment_node content_type="container" name="tomcat" version="7"/>

10 </paas_environment_template>

11 </paas_environment>

12 <paas_environment name="StorageEnv" provider="AWS" template="StorageEnvTemp">

13 <paas_environment_template name="StorageEnvTemp" memory="1024">

14 <description>64bit_Amazon_Linux_Tomcat7Java 7_RecorderHostingEnvironment</description>

15 <paas_environment_node content_type="container" name="tomcat" version="7"/>

16 <paas_environment_node content_type="database" name="DynamoDB" version="2012-08-10"/>

17 </paas_environment_template>

18 </paas_environment>

19 <paas_application_component name="simulator" environement="SimEnv">

20 <description>simulatorServlet</description>

21 <paas_application_version name="version1.0" label="1.0">

22 <paas_application_deployable name="simulator.war" content_type="artifact" location="COAPS/tmp"/>

23 <paas_application_version_instance name="Instance1" initial_state="1" default_instance="true"/>

24 <paas_application_version_instance name="Instance2" initial_state="1" default_instance="false"/>

25 </paas_application_version>

26 </paas_application_component>

27 <paas_application_component name="recorder" environement="StorageEnv">

28 <description>recorderServlet</description>

29 <paas_application_version name="version1.0" label="1.0">

30 <paas_application_deployable name="storage.war" content_type="artifact" location="COAPS/tmp"/>

31 <paas_application_version_instance name="Instance1" initial_state="1" default_instance="true"/>

32 </paas_application_version>

33 </paas_application_component>

34 </paas_application>

35 </paas_application_manifest>

Listing 1: JEE-based simulation application descriptor.

28 and the information related to its artifacts in line

30. A unique instance of this component will be

instantiated once it is deployed (line 31).

5.3 deployApplication Operation

This step implements a POST REST request that

enables the concrete deployment of the applications

components in the target PaaSs. This is done by asso-

ciating explicitly the AppIDs to the EnvIDs (see Fig-

ure 5). The upload of the components’ artifacts to the

two target PaaS is done during this step, as well as, the

wiring between the two components. DeployApplica-

tion ﬁrst processes the deployment of the Recorder

component in Elastic Beanstalk. Then, it provides

the returned public URL provided by Amazon to the

Simulator component before its deployment in Cloud

Foundry.

5.4 startApplication Operation

This step implements a POST REST request that en-

ables activating the application. The application’s

components deployed in the two PaaSs are then

started. startApplication ﬁrst starts the Simula-

tor component in Cloud Foundry before starting the

Recorder component in Elastic Beanstalk.

6 RELATED WORK

Most of the existing solutions focus on enabling in-

teroperability between cloud service providers, geo-

diversity and/or portability (Ranjan, 2014) (Martin-

Flatin, 2014) (Di Martino, 2014). Moreover, it should

be noted that most of them are made for the IaaS do-

main such as mOSAIC (Petcu et al., 2013) and Per-

fCloud (Mancini et al., 2009). For example, mO-

SAIC is a European FP7 project that aims at enabling

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

110

data, services and applications portability and inter-

operability across multiple clouds (Petcu et al., 2013).

The hosting multi-clouds system covers mainly IaaS

providers. However, mOSAIC provides platform (i.e.

Software Platform Support layer) that supports end-

user applications provisioning. mOSAIC is based on

brokering mechanisms that search for cloud services

matching the applications’ requirements. mOSAIC

framework consists of several layers (SaaS, PaaS and

IaaS) and offer a set of APIs in each one of these lay-

ers. The applications’ execution framework is pro-

vided by mOSAIC on top of a set of integrated IaaS.

The selection of the target IaaS is based on broker-

age contracts. The interactions between mOSAIC and

the IaaS providers is performed through appropriate

adaptors. Currently, mOSAIC provides adaptors for

Amazon EC2, Flexiscale, Eucalyptus and OpenNeb-

ula. mOSAIC does not meet the ﬁrst requirement re-

lated to automatic provisioning of applications across

several PaaS. It focuses mainly on IaaS providers inte-

gration. However, it meets the second requirement re-

lated to uniﬁed model and generic provisioning oper-

ations thanks to the semantic ontology for capabilities

description and the generic API exposed by the Soft-

ware Platform Support layer. On the other hand, sev-

eral projects and academic works targeted end-user

applications and PaaS domain. For example, in (Ka-

materi et al., 2013), the authors propose an approach

to semantically interconnect heterogeneous PaaS that

share the same technology. This solution was de-

veloped as part of the European FP7 Cloud4SOA re-

search project. It aims to provide better accessibil-

ity and ﬂexibility in the fragmented PaaS market.

The aggregation of the integrated PaaS capabilities in

Cloud4SOA framework is done thanks to a semantic

common ontology and a harmonized API (D’Andria

et al., 2012) . A proof-of-concept showing SOA

applications management in hybrid multi-PaaS envi-

ronment is also presented in (Zeginis et al., 2013).

Cloud4SOA partially meets the ﬁrst requirement re-

lated to the automatic provisioning of component-

based applications across several PaaS. In fact, it sup-

ports only provisioning of applications that are de-

signed according to SOA speciﬁcations. These ap-

plications are subset of the component-based applica-

tions set supported by M-COAPS. Cloud4SOA meets

the second requirement related to uniﬁed model and

generic provisioning operations thanks to the seman-

tic ontology describing the aggregated resources and

the harmonized API.

MODAClouds is a research project that aims at

supporting developers and service providers when op-

erating in a multi-cloud system (Ardagna et al., 2012).

It deﬁnes a model-driven approach to design and de-

ploy applications at large including IaaS and PaaS

applications across several clouds. PaaSage project

reuses MODAClouds basics and ﬁndings. It aims at

designing and implementing a PaaS for end-user ap-

plications development and deployment in existing

clouds (Baur et al., 2015). The deﬁned methodol-

ogy is inspired by MODAClouds model. Speciﬁcally,

when deploying an application, appropriate interfaces

and connectors are generated automatically for ap-

plication integration with user systems in northbound

and target cloud at the southbound. However, the gen-

eration process is not fully automated. It requires the

involvement of the user to provide additional infor-

mation such as the choice of cloud providers and ser-

vices, and the reuse of external services (Ferry, 2015).

Hence, MODAClouds and PaaSage did not meet the

ﬁrst requirement related to the automatic provision-

ing of applications across several PaaS. However, they

meet the second requirement related to the uniﬁed

model and provisioning operations.

PaaSHopper is a framework for operating SaaS

applications on top of a multi-PaaS environ-

ment (Walraven et al., 2015). The application’s

owner speciﬁes its properties and the required PaaS

capabilities. These properties describe the con-

straints and rules in a declarative way, extracting them

from the application code in a modular and reusable

way. Depending on the provider-speciﬁc capabili-

ties, PaaSHopper decides where in the multi-cloud a

task will be executed or data will be stored. It uses

deployment descriptor, specifying the different PaaS

platforms and resources to be used in the multi-PaaS

system. PaaSHopper meets the ﬁrst requirement re-

lated to automatic provisioning of applications across

several PaaS. However, it does not meet the second

requirement related to uniﬁed model and generic pro-

visioning operations. Indeed, even if the deployment

descriptor is based on a model, it still poor and not

rich enough to cover all the speciﬁcities and the strong

heterogeneity of the resources handled by the existing

PaaS offerings. Furthermore, it is not extensible. It is

simply based on a command-line shell (i.e. Microsoft

Windows PoweShell) and a limited set of pre-deﬁned

commands to describe the applications’ requirement

and the PaaS resources.

In (Paraiso et al., 2012), the authors present a fed-

erated multi-cloud system that enables the provision-

ing of applications described according to the Service

Component Architecture (SCA) speciﬁcations. This

approach provides a uniﬁed model and generic provi-

sioning of applications across several PaaS and IaaS

that should be provided with SCA containers. A pro-

totype is also provided (Paraiso et al., 2016). How-

ever, it only supports SCA-based applcations. Sim-

Provisioning of Component-based Applications Across Multiple Clouds

111

Table 1: Related work evaluation synthesis.

References

Requirements

R1 R2

(Kirkham, 2013) (Petcu et al., 2013) (Ferry, 2015) No Yes

(Kamateri et al., 2013) (D’Andria et al., 2012) (Paraiso et al., 2012) (Paraiso et al., 2016) Partially Yes

(Walraven et al., 2015) Yes No

(Cunha et al., 2014) Yes Not mentioned

(Pahl, 2015) (Hadley et al., 2015) (Wei et al., 2011) (Ardagna et al., 2012) No No

ilarly, the targeted cloud environments should also

support SCA containers. This work partially meets

the ﬁrst requirement related to the automatic provi-

sioning of component-based applications across sev-

eral PaaS. It supports only provisioning of SCA-

based applications that are designed according to

SOA speciﬁcations which are subset of SOA appli-

cations. Moreover, it meets the second requirement

related to uniﬁed model and generic provisioning op-

erations thanks to the introduced mapping model in

between the cloud offerings.

In (Wei et al., 2011), the authors introduce Ap-

plication Platform-as-a-Service for Cloud Computing

called Aneka. It acts as a framework for building cus-

tomized applications and deploying them on either

public or private clouds. Basically, Aneka does not

support multi-PaaS environment. But, a newly added

extension supports distributed end-user applications

deployment in multi-cloud environments (Buyya and

Barreto, 2015). To illustrate the beneﬁts of the new

extension, the authors deploy an application com-

posed of independent tasks by Aneka in multi-cloud

environment using resources provisioned from Mi-

crosoft Azure and Amazon EC2. Aneka does not en-

able automatic provisioning and does not provide any

uniﬁed model and/or generic provisioning operations.

Consequently, it does not meet the two requirements.

In (Brogi et al., 2015), the authors provide an

open source framework called SeaClouds to address

the problem of deploying, managing and reconﬁg-

uring complex applications over multiple and het-

erogeneous clouds. This framework is based on

Topology and Orchestration Speciﬁcation for Cloud

Applications (TOSCA) speciﬁcations to describe the

topology of the applications independently of the tar-

get cloud providers and Cloud Application Manage-

ment for Platforms (CAMP) API for its manage-

ment. TOSCA and CAMP are standardization ten-

tatives within OASIS consortium. SeaClouds auto-

mates the provisioning process using CAMP API op-

erations; however, it imposes the support of TOSCA-

enabled containers for the target PaaS. Consequently,

it partially the ﬁrst requirement related to the auto-

matic provisioning of component-based applications

across several PaaS. In addition, it meets the second

requirement related to uniﬁed model and generic pro-

visioning operations thanks to a mapping model in be-

tween the cloud offerings.

In (Cunha et al., 2014), the authors propose a

framework denominated PaaS Manager that aims to

struggle the existing lock-in in the PaaS market. PaaS

Manager is intended to ﬁt the many developer’s needs

in a multi-PaaS environment, such as developing

and deploying applications, monitor operation date

in real-time and migrate applications between PaaS

offerings. Hence, it meets the ﬁrst requirement re-

lated to automatic provisioning across several PaaS.

To deal with the multi-PaaS environment, the user can

ﬁll a form with the technical proﬁle of the application

through a command-line or a Web interface. How-

ever, the authors did not detail on the properties that

the user may enter.

Finally, it should be noted that several works use

the containerization approach to enable distributed

applications deployment across several clouds (e.g.

see (Pahl, 2015), (Hadley et al., 2015)). These

approaches consists on packaging the applications’

components dynamically in a generated service con-

tainers. The generated service containers imple-

ment the applications’ components requirements (e.g.

required runtime, libraries). Then, the contain-

ers are pushed to the cloud as standalone applica-

tions. These approaches require manual deployment

through command-line and do not provide any uniﬁed

model and/or provisioning operations. Hence, they do

no meet the two evaluation requirements.

Table 1 provides a summary of the critical evalua-

tion provided in this section.

7 CONCLUSIONS AND FUTURE

WORK

This paper presents M-COAPS API for component-

based applications provisioning across several PaaS

offerings. This approach uses and extends COAPS

API that relies on a generic OCCI-based descrip-

tion model. M-COAPS provides a concrete solu-

tion to struggle the existing lock-in in the PaaS mar-

ket and enables developers to deploy and manage

their applications’ components easily and seamlessly

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

112

in multi-PaaS environment. For example, the devel-

opers henceforth can use a unique and common de-

scriptor when deploying the components in hetero-

geneous PaaS solutions. Moreover, they can man-

age (e.g. starting) the components in the same way

whatever the target PaaS is. The implementation of

the motivating use case was performed to validate

the proposed approach and demonstrate its feasibility.

Such approach can be considered as a step forward to

achieve PaaS cooperation and federation. It also pro-

vides concrete perspective to enable cloud end-user

applications portability. Furthermore, unlike the re-

viewed related work, M-COAPS and its associated

OCCI model do not impose any integration contraints

and/or modiﬁcations from the providers side which

makes easy its adoption.

As next steps in the future, the integration of this

solution to the open source CompatibleOne cloud

broker is contemplated. In addition, the design and

the implementation of a placement algorithm that

can be integrated is also considered. Such algo-

rithm will provide M-COAPS with the optimal com-

ponents placement plan when deploying an applica-

tion . Placement decisions will be based on well-

deﬁned requirements (e.g. cost, latency). Finally, the

inclusion of migration capability is planned. It will

enable moving components from one PaaS to another

during runtime. The moving decisions can be trig-

gered by events such as a rate change in the hosting

PaaS.

REFERENCES

(2016). COAPS API Web Page. http://www-inf.it-

sudparis.eu/SIMBAD/tools/COAPS/.

Ardagna, D., Di Nitto, E., Casale, G., Petcu, D., Mo-

hagheghi, P., Mosser, S., Matthews, P., Gericke, A.,

Ballagny, C., D’Andria, F., et al. (2012). Modaclouds:

A model-driven approach for the design and execution

of applications on multiple clouds. In Proceedings of

the 4th International Workshop on Modeling in Soft-

ware Engineering, pages 50–56. IEEE Press.

Baur, D., Wesner, S., and Domaschka, J. (2015). Advances

in Service-Oriented and Cloud Computing: Work-

shops of ESOCC 2014, Manchester, UK, September

2-4, 2014, Revised Selected Papers, chapter Towards

a Model-Based Execution-Ware for Deploying Multi-

cloud Applications, pages 124–138. Springer Interna-

tional Publishing, Cham.

Brogi, A., Fazzolari, M., Ibrahim, A., Soldani, J., Carrasco,

J., Cubo, J., Dur

an, F., Pimentel, E., Di Nitto, E., and

D Andria, F. (2015). Adaptive management of ap-

plications across multiple clouds: The seaclouds ap-

proach. CLEI Electronic Journal, 18(1):2–2.

Buyya, R. and Barreto, D. (2015). Multi-Cloud Resource

Provisioning with Aneka: A Uniﬁed and Integrated

Utilisation of Microsoft Azure and Amazon EC2 In-

stances. arXiv preprint arXiv:1511.08857.

Cunha, D., Neves, P., and Sousa, P. (2014). PaaS manager:

A platform-as-a-service aggregation framework.

D’Andria, F., Bocconi, S., Cruz, J. G., Ahtes, J., and

Zeginis, D. (2012). Cloud4SOA: multi-cloud appli-

cation management across PaaS offerings. In Sym-

bolic and Numeric Algorithms for Scientiﬁc Comput-

ing (SYNASC), 2012 14th International Symposium

on, pages 407–414. IEEE.

Dash, D., Kantere, V., and Ailamaki, A. (2009). An Eco-

nomic Model for Self-Tuned Cloud Caching. In Data

Engineering, 2009. ICDE ’09. IEEE 25th Interna-

tional Conference on, pages 1687–1693.

Di Martino, B. (2014). Applications portability and services

interoperability among multiple clouds. IEEE Cloud

Computing, (1):74–77.

Ferry, N. (2015). MODAClouds evaluation report–Final

version.

Grossman, R. (2009). The Case for Cloud Computing. IT

Professional, 11(2):23–27.

Hadley, J., Elkhatib, Y., Blair, G., and Roedig, U.

(2015). Multibox: lightweight containers for vendor-

independent multi-cloud deployments. In Embracing

Global Computing in Emerging Economies, pages 79–

90. Springer.

Kamateri, E., Loutas, N., Zeginis, D., Ahtes, J., D’Andria,

F., Bocconi, S., Gouvas, P., Ledakis, G., Ravagli,

F., Lobunets, O., et al. (2013). Cloud4SOA: A

semantic-interoperability paaS solution for multi-

cloud platform management and portability. In

Service-Oriented and Cloud Computing, pages 64–78.

Springer.

Kirkham, T. (2013). Keith Je rey. PaaSage Project. Model

Based Cloud Platform Upperware. Initial Architecture

Design. Technical report, Technical report, Novem-

ber.

Mancini, E. P., Rak, M., and Villano, U. (2009). Perf-

cloud: Grid services for performance-oriented devel-

opment of cloud computing applications. In Enabling

Technologies: Infrastructures for Collaborative En-

terprises, 2009. WETICE’09. 18th IEEE International

Workshops on, pages 201–206. IEEE.

Martin-Flatin, J. (2014). Challenges in Cloud Management.

IEEE Cloud Computing, (1):66–70.

Mell, P. and Grance, T. (2009). The NIST deﬁnition of

cloud computing. National Institute of Standards and

Technology, 53(6):50.

Metsch, T. and Edmonds, A. (2011). Open Cloud Comput-

ing Interface - RESTful HTTP Rendering. Technical

report.

OCCI (2016). OCCI. Open Cloud Computing Interface.

http://occi-wg.org/.

Pahl, C. (2015). Containerization and the PaaS cloud. IEEE

Cloud Computing, (3):24–31.

Paraiso, F., Haderer, N., Merle, P., Rouvoy, R., and Sein-

turier, L. (2012). A federated multi-cloud PaaS in-

frastructure. In Cloud Computing (CLOUD), 2012

IEEE 5th International Conference on, pages 392–

399. IEEE.

Provisioning of Component-based Applications Across Multiple Clouds

113

Paraiso, F., Merle, P., and Seinturier, L. (2016). socloud:

a service-oriented component-based paas for manag-

ing portability, provisioning, elasticity, and high avail-

ability across multiple clouds. Computing, 98(5):539–

565.

Petcu, D., Di Martino, B., Venticinque, S., Rak, M., M

ahr,

T., Lopez, G. E., Brito, F., Cossu, R., Stopar, M.,

Sperka, S., et al. (2013). Experiences in building a

mOSAIC of clouds. Journal of Cloud Computing,

2(1):1–22.

Ranjan, R. (2014). The Cloud Interoperability Challenge.

Cloud Computing, IEEE, 1(2):20–24.

Satzger, B., Hummer, W., Inzinger, C., Leitner, P., and

Dustdar, S. (2013). Winds of change: From vendor

lock-in to the meta cloud. IEEE Internet Computing,

(1):69–73.

Sellami, M., Yangui, S., Mohamed, M., and Tata,

S. (2013a). Open Cloud Computing Interface-

Application. Technical report, Tech. Rep.,

2013.[Online]. Available: http://www-inf. int-

evry. fr/SIMBAD/tools/OCCI/occi-application. pdf

86, 94.

Sellami, M., Yangui, S., Mohamed, M., and Tata, S.

(2013b). PaaS-independent Provisioning and Man-

agement of Applications in the Cloud. In Cloud Com-

puting (CLOUD), 2013 IEEE Sixth International Con-

ference on, pages 693–700. IEEE.

Walraven, S., Van Landuyt, D., Raﬁque, A., Lagaisse, B.,

and Joosen, W. (2015). PaaSHopper: Policy-driven

middleware for multi-PaaS environments. Journal of

Internet Services and Applications, 6(1):1–14.

Wei, Y., Sukumar, K., Vecchiola, C., Karunamoorthy, D.,

and Buyya, R. (2011). Aneka cloud application plat-

form and its integration with windows azure. arXiv

preprint arXiv:1103.2590.

Yangui, S., Marshall, I. J., Laisn

e, J., and Tata, S. (2014).

CompatibleOne: The Open Source Cloud Broker. J.

Grid Comput., 12(1):93–109.

Yangui, S., Mohamed, M., Sellami, M., and Tata,

S. (2013). Open Cloud Computing Interface-

Platform. Technical report, Tech. Rep., 2013.[On-

line]. Available: http://www-inf. int-evry.

fr/SIMBAD/tools/OCCI/occi-platform. pdf 86,

94.

Yangui, S. and Tata, S. (2016). An OCCI compliant model

for paas resources description and provisioning. Com-

put. J., 59(3):308–324.

Zeginis, D., D’Andria, F., Bocconi, S., Gorronogoitia Cruz,

J., Collell Martin, O., Gouvas, P., Ledakis, G., and

Tarabanis, K. A. (2013). A user-centric multi-PaaS ap-

plication management solution for hybrid multi-Cloud

scenarios. Scalable Computing: Practice and Experi-

ence, 14(1).

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

114