PaciﬁcClouds: A Flexible MicroServices based Architecture for

Interoperability in Multi-Cloud Environments

Juliana Oliveira de Carvalho

1,2,3

, Fernando Trinta

and Dario Vieira

Federal University of Cear´a (UFC), Fortaleza, Brazil

EFREI-Paris, Paris, France

Federal University of Piau´ı (UFPI), Picos, Brazil

Keywords:

Multi-cloud, Microservices, Interoperability.

Abstract:

Cloud Computing has become a popular IT service delivery model in recent years. While the cloud brings

several beneﬁts, there are still some challenges that need to be overcome to apply the cloud model in certain

scenarios. One such problem is the so-called vendor lock-in since different cloud providers offer peculiar and

often incompatible services, which results in the automatic migration impossibility of the application between

cloud providers. This issue becomes even more problematic when thinking of future applications composed of

services or components hosted by different cloud providers in a multi-cloud environment. Dealing with ven-

dor lock-in in multiple clouds requires addressing two important challenges: interoperability and portability.

Some solutions have been proposed to deal with both problems, but most of them fail to provide ﬂexibility.

Therefore, we propose PaciﬁcClouds, a novel architecture based on microservices for addressing interopera-

bility in a multi-cloud environment. PaciﬁcClouds differs from previous works by providing greater ﬂexibility

due to the microservices architectural pattern. In this article, we also propose a deﬁnition of microservices

and a comparative analysis of the works related to PaciﬁcClouds. Finally, we show the main challenges of

PaciﬁcClouds, and we point out the future directions.

1 INTRODUCTION

Cloud co mputing represents the consolidation of the

utility computing idea, i.e., users access the cloud

as a service and utilize resources such as hardware,

software and storage through a contract with a pro-

vider and pay for consumption according to e stablis-

hed policies. Furthermore, cloud computing resour-

ces seems like a n inexhaustible source of virtualized

resources for the user; in consequence, the clou d al-

lows the systems elastic growth (Vaquero et al., 2009).

Facing the cloud computing’s success, cloud pro-

viders proliferate rapid ly; each one them wants to of-

fer infrastructure, platfo rm, and services to satisfy the

needs of its users in such a manner that they do not

want to use other providers. The infrastructure and

services of a provider differ somewhat from other s.

Therefore, providers become considerably speciﬁc.

Thus, the problem known as ven dor lock-in arises

as a consequence the user applications a re dependent

on a single cloud provider technology. According to

(Opara-Martins et al., 2015), vendor lock-in is one of

the barriers to the adoption of cloud computing. The

research further po ints out that organizations’ desire

to adopt the cloud for their beneﬁt is primarily related

to capacity, scalability, and speed, but they consider

urgent the vendor loc k-in treatment.

One method for treating vendor lock-in is the use

of multiple clouds, although a small number of en-

terprises ado pt this approach, their popularity is in-

creasing. One reason for the low adoption of multi-

ple clouds is cloud providers interest lack to promote

interoperability and portability (Grozev a nd Buyya,

2014). According to this context, (Opara-Martins

et al., 20 15) observes the need for dealing with in-

teroperability and portability in ord er to m itigate the

problem of vendor lock-in. Section 2 describes mul-

tiple clouds, interoperability and portability.

In addition, (Opara-Martins et al., 2 015) still notes

that no a pproach exists that meets the needs o f enter-

prises. Some of the reasons there is no proposed so-

lution widely adopte d to mitigate vendor lock-in are:

most so lutions are inﬂexible; software arc hitects must

adopt speciﬁc tech nologies for the application deve-

lopment with a steep learning curve, (Petcu, 2013).

In consideration of these limitations, the applica-

448

Oliveira de Carvalho, J., Trinta, F. and Vieira, D.

PaciﬁcClouds: A Flexible MicroServices based Architecture for Interoperability in Multi-Cloud Environments.

DOI: 10.5220/0006705604480455

In Proceedings of the 8th International Conference on Cloud Computing and Services Science (CLOSER 2018), pages 448-455

ISBN: 978-989-758-295-0

tions must be designed and developed as native cloud

applications. For that matter, the applications are built

with the focus on integra tion w ith the cloud model, to

obtain full cloud advantages; it, also ensures other fe-

atures lab eled as IDEAL (Isolated state, Distribution,

Elasticity, Au tomated management, Loose co upling).

In this manner, the native cloud a pplication can faci-

litate the application deployment in multiple clo uds,

hence help treat interope rability a nd p ortability (Feh-

ling et al., 2014).

Microservices can aid in o btaining the na tive

cloud application’s characteristics; the refore, they fo-

cus on aspects as compon entization of small and lig-

htweight services, agile and DevOps practices, in-

frastructure automation with continuous delivery fe-

atures, decentralized data management, and decen-

tralized governance among services. The microser-

vices promise more agility, more delivery speed, and

more scalability compared with traditiona l monolithic

applications, resulting in less overall cost (Newman,

2015), (RV, 2016). In Section 3, we describe, present

challenges a nd pr opose a deﬁnition for microservices.

In this work, we propose a novel architecture ba-

sed on microservices to address interoperability f or a

multi-cloud environment, called PaciﬁcClouds, in or-

der to mitigate vendor lock-in and aid to obtain full

cloud advantages. PaciﬁcClouds promo tes ﬂexibility

for user’s decisions related to requirements and ap-

plication architecture, a nd for choosing the clouds to

execute each microservice of the application. There-

fore, PaciﬁcClouds differentiate from the other works

as it possesses features related to the use of the micr o-

service and native cloud applica tion, and mainly due

to the ﬂexibility. In Section 4, we pre sent in details

PaciﬁcClouds.

PaciﬁcClouds is ﬂexible as it allows the use of se-

veral independent cloud providers. The providers can

use different technology backgr ounds and let software

architects utilize several techniques in developing the

applications, update the software and the user and ap-

plication requirements at runtime. The proposed ar-

chitecture is lightweight, since each module is respon-

sible only for one business logic. It possesses decen-

tralized governance of the applica tion because each

part o f the application is independent of one another,

i.e., the a pplication m odules possess lo osely co upled.

The applications are native cloud applications based

on microservices. Thus, the ap plications can be de-

ployed/redeployed/updated at runtime, analyzing the

application requirements and the user’s SLA. The re-

fore, software architec ts do not need to be concer-

ned with the cloud selections, application deploymen t

and what technologies are used in application deve-

lopment. In addition , th ey can request, in runtime, a

new SLA b y ana lyzing the monitoring metr ics.

According to the context aforementioned, the con-

tributions of this article are given below:

• The proposition and description of PaciﬁcClouds,

a n ovel architecture, which provides greater ease

in the development of native cloud application,

and more ﬂexibility in the deployment and exe-

cution of an application in multiple clou ds envi-

ronment because of m ic roservice use.

• A more comprehensive deﬁnition of microservic e .

• A comparative an a lysis of the works related to Pa-

ciﬁcClouds. The related work are described in

Section 5 and a discuss is presented in Section 6.

Last, in Section 7, we show this work’s primary

contributions, describe PaciﬁcClouds’ main develo-

ping challenges and discuss future directions.

2 MULTIPLE CLOUDS

Multiple clouds enable applications to take advantage

of the best features of different compo nents provided

by several cloud providers. Since there is still no stan-

dardized taxono my for the su bject, different terms are

used in the literature and they often have the same

meaning or they are a branch of an existing one.

In this work, we adopt the deﬁnition s used by (Pe-

tcu, 2014b), who classiﬁes different multiple cloud

application scenarios as delivery models and presents

three main proposals for these models. Th e ﬁrst, cal-

led multi-cloud, is a delivery model that does not in-

clude a prior agreement among the clo ud providers,

a third party assumes the role of intermed ia ry. In

a cloud federation, the second delivery model exists

as an established c ollaboration arrangement among

cloud provide rs to share their resources. The third

delivery model, called inter-cloud, can be on both a

cloud federa tion and multi-cloud, but the scalab le and

opportunistic services must be dynamic, and inter-

cloud must possess the cloud br oker, wh ich is an in-

termediary actor in the relationship between the pro-

vider and the consumer.

The use of multip le clou ds brings several advanta-

ges, and thro ugh them , we can achieve the full bene-

ﬁts of cloud pr operties such as elasticity and pay-as-

you-go (Mezg´ar and Rauschecker, 2014), (Silva et al.,

2013). However, the multiple clouds bring several

challenges, as well, e.g., interoperability and porta bi-

lity related to mitigating vend or lock-in. We consider

portability the ability to allow customers to migrate

data and systems from one cloud to another and inter-

operab ility capacity to a llow customers to use servi-

ces across multiple clouds (Rezaei et al., 2 014).

PaciﬁcClouds: A Flexible MicroServices based Architecture for Interoperability in Multi-Cloud Environments

449

3 MICROSERVICES

In the literature, micro services have several deﬁniti-

ons; in this section, we present f our of them and pro-

pose a deﬁnition for micro services. In addition, we

present the main challenges of microservices.

According to (Newman, 2015), microserv ices are

small, autonomous services tha t work together. In the

second deﬁnitio n, given b y (Pautasso et al., 2 017), mi-

croservices are an architectural sty le as an approach

to developing a single application a s a suite of small

services, each running in its process and communica-

ting with lightweight mecha nisms, o ften an Http re-

source. In the deﬁnition provided by (RV, 2016), mi-

croservices are an architectural sty le or an approach

to building IT systems as a set of building capabilities

that are autonomous self-co ntained, and loosely cou-

pled. Last, (Dr agoni and Lluch-laf uente, 2016) pro-

posed two deﬁnitions related to microservices: one

for m icroservice and an other for microserv ic e ar chi-

tecture. Therefore, microservice is a cohesive, inde-

pendent process interacting via messages, and micro-

service architecture is a distributed ap plication where

all its modules ar e microservices.

We propose a deﬁnition for microservices based

on the deﬁnitions cited in this work, because we un-

derstand that our deﬁnition of microservices shows

the meaning of microser vices in the context of multi-

clouds and more speciﬁcally in a scen a rio which th e

application is distributed over multiple clouds.

Deﬁnition (Microservices): are a set of autonomous,

indepen dent, self-contained services, in which each

service has a single goal, is loosely coupled, and inte-

ract to build a distributed ap plication. Although there

are several beneﬁts of the microservices, they po s-

sess some challenges. The main challenges related to

the adoption of microserv ic es in the construction of a

system ar e: (i) The software architects must change

the manner of thinking systems design; (ii) the com-

plexities of th e distributed systems; (iii) the need for

scaling the systems differently a nd ensuring that mi-

croservices are resilient (Dragoni and Lluc h-lafuente,

2016).

4 PaciﬁcClouds

In order to promote greater adoption of cloud com-

puting, we propose PaciﬁcClouds to mitigate vendor

lock-in. PaciﬁcClouds is a novel architecture that

addresses the interoperability of distributed ap plica-

tion in multiple clouds via microservices. Thus, Pa-

ciﬁcClouds intends to pr ovide ﬂexibility for the so ft-

ware architect both in making decisions r elated to ap-

plication requirements an d the use of the clouds. In

addition, PaciﬁcClouds can migrate microservice in

runtime to better me et application and user needs.

In this section, we describe a scenario that shows

some of the PaciﬁcClouds contributions. Next, we

introdu ce and explain the PaciﬁcClouds architecture.

4.1 Scenario

In this section, we describe a scenario of a web ap-

plication designed an d deployed in to a fashio n store

named AnaGomesFashion, which is expanding its cu-

stomers as well as the frontiers of action. AnaGo-

mesFashions is a store tha t sells beachwear, intimate

and ﬁtness fashion. Each fashion segment has several

suppliers distributed in Brazil’s states. It also o ffers

specialized services to its clients through p a rtnerships

with nutritionists, physiotherapists, and person a l trai-

ner. AnaGomesFashions’ online store allows access

to its clients through desktop or mobile phone. The

application has three types of user s: Client, Professi-

onalService, and AnaGomesFashions.

Client use the a pplication to purc hase products as

well as to get the pro fessional services offered by

the stor e. ProfessionalService users are professio-

nals who pa rtnered with the store to offer services to

AnaGomesFashions’ clients. The AnaGomesFashi-

ons user is responsible for registering products and

suppliers, as well as monitoring sales, services and ﬁ-

nances.

AnaGomesFashions virtual fashion store offers a

variety of services such as: thr ee fashion segments

sales service; product ﬁtting service according to the

client’s body; services provided in partnership with

three types of professional; progre ss monitoring ser-

vice; f ollow-up service for the delivery process, by

the customer a nd by the store; sales analysis to help

determine which products should be purchased from

the store through its suppliers; after-sales ser vice to

analyze customer satisfaction regarding the products

and services offered b y AnaGomesFashions.

4.2 PaciﬁcClouds Architecture

According to the PaciﬁcClouds goals described in

section 1, we adopt the multi-cloud de livery mode l,

for it b rings greater ﬂexibility. In relation to porta-

bility, we assume the three categories used by (Pe-

tcu et al., 2013) and we report the IaaS and PaaS le-

vels for the portability requirements. According to

interoperability levels, we have considered the follo-

wing criteria, (Nogueira et al., 2016): we have ado p-

ted both syntactic and semantic level interoperability,

associated with the agreement level. Regarding the

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

450

adoption level, we assume the communica tion mecha-

nisms adop ted for microserv ic e s. Related to th e de-

ployment level, we consider both horizontal and ver-

tical interoperability in IaaS and PaaS service models.

We assum e the asynchronous communication in the

interactions patterns between cloud levels. Finally,

associated with th e en d-user level, we adopted user-

centric interoperability.

PaciﬁcClouds intends to add ress interoperability

in the multi-cloud that focuses on the user’s per-

spective through microservices and native cloud ap-

plications. In this manner, it also addresses an imp or-

tant issue related to the adoptio n of cloud computing,

ﬂexibility. Thus, in th is subsection, we present and

describe the architecture PaciﬁcClouds.

In order for architecture to cover all objectives of

PaciﬁcClouds, aforementioned in this article, it must

include the following functionalities: (i) identify the

application microservices as well as its requirem ents;

(ii) identify user req uirements; (iii) discover and mo-

nitor the capabilities o f the available clouds; (iv) ma-

nage the application deployment and execution; (v)

monitor the deployment and execution of each ap pli-

cation microservic e; (vi) monito r user and application

requirements, as well as the capabilities of the clouds

involved in running the application; (vii) provide the

deployment of each application microservice; (viii)

manage the cloud resources of each application mi-

croservice; (ix) provide application performance in-

formation to the user, as that the user can mod ify the

requirements at r untime. Therefore, PaciﬁcClouds ar-

chitecture consists of three parts: PaciﬁcClouds API,

Adapter, paciﬁcClouds Core. The Figure 1 illustra-

tes the PaciﬁcClouds architecture; after, we describe

each PaciﬁcClouds architecture component.

Figure 1: PaciﬁcClouds Architecture.

PaciﬁcClouds API is th e communication inter-

face betwe en the software architect and the Paci-

ﬁcClouds Core. The PaciﬁcClouds API receives two

artifacts from the sof tware architect: the application

and users’ SLA, which it sends to the PaciﬁcClouds

Core. T he PaciﬁcClouds Core pr ovides information,

for the sof tware architect via PaciﬁcClouds API, both

about resources used by an application and about ap-

plication and user’s req uirements.

Adapter is the c ommun ication inte rface between

the multiple available clouds and the PaciﬁcClouds

Core. The adapter sends the capabilities and inform a-

tion about the cloud resources used by the application

to PaciﬁcClouds Core. it also sends the microservices

received from the PaciﬁcClouds Core to the clouds.

PaciﬁcClouds Core is the central par t of the ar-

chitecture. It is responsible for discovering the ap-

plication microservices and their respective r equire-

ments; determinin g the clou ds; deploying the micro-

services; managing cloud resources used by the ap-

plication; monitoring information about the resources

used b y the application at runtime; monitoring all ca-

pabilities of the clouds; and verifying the user requi-

rements. Therefore, it is composed of six microser-

vices to perfo rm all its tasks. These microservices

themselves communicate through synchro nous calls

and asynchronous events. In the next subsections, we

describe these microservices.

4.2.1 Application Management Service

Application Manag ement Service (AM S) receives an

application from the PaciﬁcCloud API and it is re-

sponsible for registering it in the AppData (via Ap-

plications Register Service (ARS)) and sending it to

the Microservices Identiﬁcation Service (MIS). Then,

the AMS extracts each application microservice (via

MIS), in addition to the requ irements of each micro-

service and the user (via Requirements Discovery Ser-

vice (RDS)). In addition, the AMS registers the user

proﬁle in the USrData (via Users Register Service

(URS)), according to Figure 2.

Figure 2: The services of the AMS microservice.

4.2.2 SLA Service

Figure 3 illustrates the SLA Service, which is respon-

sible for mapping the user’s and microservice’s requi-

rements received from the AMS, as well as the cloud

resources data used by the application received from

PaciﬁcClouds: A Flexible MicroServices based Architecture for Interoperability in Multi-Cloud Environments

451

the Monitoring Service (via Data Mapping Service

(DMS)). In a ddition, the SLA Service develops pro-

cedures and methods for evaluating and reporting in-

formation on the application performaence to the soft-

ware ar chitect (via Data Analysis Service (DAS)).

Figure 3: The services of the SLA Service microservice.

4.2.3 Notiﬁcation Service

Notiﬁcation Service, shown in Figure 4, is responsib le

for notifying DPGS microservice (via Deployment

Notiﬁcation Service (DplNS)) about changes in the

user requirements or the microservice requirements,

or the updating of the application; it also informs

DPGS about violation of the criteria by cloud, regis-

ters the notiﬁcation data in DplNData and notiﬁes the

software architect for deploying or r edeploying of the

application (via User Notiﬁcation Service (UsrNS)).

Figure 4: The services of the Notiﬁcation microservice.

4.2.4 Monitoring Service

Monitoring Service, shown in Figure 5, is responsi-

ble for monitoring the cloud resou rces used by th e

application at runtime through the adapter. M oni-

toring Serv ic e is composed by three services: (i)

Cloud Resources Register Service (CRRS) receives

from DPGS the deploym ent p la n data. After, it re-

gisters it in MsRsData and it sends it to CRDAS; (ii)

Cloud Resources Detec tion Service (CRDetS) detects

all capabilities of the clouds, which are deployed by

the microservices. Next, it sends them to CRDAS;

(iii) Cloud Resource Data Analysis Service( CRDAS)

is responsible for comparing the application perfor-

mance received from CRDS with the deploymen t plan

data; next, it sends the cloud resources data used by

the application to SL A Service and sends a notiﬁca-

tion to Notiﬁcation Service if any violation happens.

Figure 5: The service of the Monitoring microservice.

4.2.5 Deployment Plan Generation Service

The Figure 6 illustrates Deployment Plan Gener a tion

Service (DPGS), which determines the cloud provi-

ders for deploying the microservices without viola-

ting application and user requirements via Cloud Se-

lection Service (CSS). For this, it receives from the

SLA Service all requirements. Afterward, it must

generate a microservices deploym ent plan based on

the requireme nts and the capabilities of the clouds

obtained by Cloud Capabilities Discovery Service

(CCDS). Also, it analyzes the notiﬁcations received

from Notiﬁcation Service and the requirements recei-

ved from SLA service; next, if nece ssary, it generates

a rede ployment plan of some microservices.

Figure 6: The deployment plan generation microservice.

4.2.6 Deployment Service

Deployment Service, illustrated in Figure 7, recei-

ves the micr oservices from AMS through Application

Microservices Reception Service ( AMRS), besides

registering eac h microservic e in McsData. Next, De-

ployment Service identiﬁes the cloud for ea ch micro-

service according to dep loy plan via Microservice As-

sociation Service (MAS); after, it deploys the micro-

services via Microserv ic e Deployment Service (MD-

plS).

We can observe that PaciﬁcClouds intends to ma-

nage th e deployment and execution proc ess of the dis-

tributed application in multiple clo uds to better me et

the needs of the app lication and c onsequently im-

prove end-user satisfaction with the application per-

formance. Thus, the PaciﬁcClouds will be able to

help the software architecture in the process of d e -

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

452

Figure 7: The Deployment Service.

signing and developing the ap plication. For this, Pa-

ciﬁcClouds must identify eac h of th e services offe-

red by the application, as well as its re quirements. In

addition, PaciﬁcClouds must selec t the most suitable

clouds for each one of the application services, and to

deploy each of the application services according to

the clouds selection pro cess. The PaciﬁcClouds mu st

also monitor application execution by observing the

clouds involved in the application deployment to de-

tect any violation of requirements, and monitor chan-

ges in application requirements, application services’

updates and capa bilities of the clouds to identify the

need to re-deploy some ap plication services.

5 RELATED WORK

In this section, we describe an overview of the six

most relevant work s related to PaciﬁcClouds in regars

to tre a ting the intero perability in multiple clouds, in

which each of th em proposes a different solution to

mitigate vendor lock-in.

Cloud4SOA introduce s a broker-based architec-

ture whose primary goal is to address semantic in-

teroperability challenges at the PaaS layer, based on

SOA architecture (Dandria et al., 2012). The mO-

SAIC aims at offering access to heterogeneous re-

sources from multiple clouds. Under a high-level

perspective, an API an d a PaaS compose the mO-

SAIC, which PaaS allows us to deploy, conﬁgure and

manage application s running on IaaS. (Petcu et al.,

2013).

MODAClouds offers a set of tec hniques for deve-

lopment and r untime oper ation management of mul-

tiple clouds applications. It delivers an open-source

IDE for the high-level design, cloud service selection,

early pr ototyping, QoS assessments, sem i-automatic

code generation , and multiple cloud applications au-

tomatic deployment (Ardag na et al., 2012). The RA-

SIC focuses on resolving the semantic interoperabi-

lity issues in IaaS and introducing a user-centric ap-

proach for applications that use cloud resources. I t fa-

cilitates the smooth switching among cloud providers

and allows the composition and services integration

of different clouds (Loutas e t al., 2010).

Automated Setup of Multi-Cloud Environments

for Microservices Applications proposes an automa-

ted approach for the selection and c onﬁgura tion of

cloud providers for microservices based applications.

But it does not deal directly with applications deploy-

ment and does not consider costs and quality o f ser-

vice for optimizing the selection as these depend he-

avily on application usage (Sousa et al., 2016). The

SeaClouds focuses on dep loying and managing com-

plex multi-component applications over heterogene-

ous clouds. The approach is based on the c oncept of

service orchestration and is designed to fu lﬁll functi-

onal and non-functional properties of the application .

In addition, the services can be deployed, replicated,

and administered using standard harmon iz ed APIs

such as CAMP speciﬁcation and Cloud4SOA (Bro gi

et al., 2015).

6 DISCUSS

In this section, we present an analysis of the works

described in Section 5 a nd the PaciﬁcClouds. For this,

we offer a summary of the features of all the soluti-

ons de scribed in this article, including PaciﬁcClouds,

related to promo ting interoperability in a multi-cloud

environme nt. We consider 10 aspects describ ed in this

article, beca use through them we can observe the le-

vel of ﬂexibility of a given solution.

In Table 1, there is the only aspect th at all soluti-

ons promote the semantic interoperability. So me so-

lutions u se the semantic interoper a bility in the ap pli-

cations portability, while others use it in the interope-

rability between application modules distributed over

multiple clouds, and it includes solutions that use it to

treat vertical interopera bility between service models.

One of the characteristics described in Table 1

refers to the service model used by the solutio ns.

MODAClouds and ASMEMA treat interoperability in

the three primary service models: IaaS, PaaS, and

SaaS. Despite addressing the three levels, MODA-

Clouds only addresses horizontal interoperability for

cloud federation. ASMEMA does not address any of

the vertical and horizontal interope rability levels fo r

the multi-cloud delivery model. Two other solutions,

Cloud4SOA and RASIC, address interoperability in

only one of the service mo dels. Cloud4SOA addres-

ses interoper ability at th e PaaS level; it does not ad-

dress any vertical and horizontal inter operability le-

vels, and it uses the hybrid delivery model, which is

a cloud federation th a t has a private cloud and at lea st

one public cloud (Petcu, 2014a). RASIC treats inter-

operab ility in the IaaS service model for multi-cloud

PaciﬁcClouds: A Flexible MicroServices based Architecture for Interoperability in Multi-Cloud Environments

453

Table 1: Summary of the characteristics the related work with PaciﬁcClouds.

Projects Characteristics

Solutions for Multiple Clouds

Cloud4SOA mOSAIC MODAClouds RASIC ASMEMA SeaClouds PaciﬁcClouds

Service Model

PaaS IaaS/PaaS IaaS/PaaS/SaaS IaaS IaaS/PaaS/SaaS IaaS/PaaS IaaS/PaaS/SaaS

Delivery Mode l

Hybrid Hybrid Cloud Federation Multi-Cloud Multi-Cloud Multi-Cloud Multi-Cloud

Portability

✔ ✔ ✔ ✘ ✘ ✔ ✔

Vertical Interoperability

✘ ✔ ✘ ✘ ✘ ✔ ✔

Horizontal Interoperability

✘ ✘ ✔ ✔ ✘ ✔ ✔

Application Distributed

✘ ✘ ✘ ✔ ✔ ✔ ✔

Different Technological

Background

✘ ✔ ✔ ✔ ✔ ✘ ✔

Semantics

✔ ✔ ✔ ✔ ✔ ✔ ✔

Flexibility

✘ ✘ ✘ ✘ ✔ ✘ ✔

Decentralized G overnance

✘ ✘ ✘ ✘ ✘ ✘ ✔

✔ The work has the characteristic ✘ The work does not have the characteristic

but addresses only the hor iz ontal inter operability le-

vel. Finally, m O SAIC, SeaClouds, and PaciﬁcClouds

treat interoperability in the IaaS and PaaS service mo-

dels. mOSAIC uses the hybrid delivery model; it de-

als with vertical inte roperability as it makes applica-

tion portability. SeaClouds and PaciﬁcClouds address

vertical and horizontal interoperability levels fo r the

multi-cloud delivery model as well as promote app li-

cation portability.

RASIC, ASMEMA, SeaClouds, and Paci-

ﬁcClouds address interoper ability for distributed

applications in multiple clouds g e ographically

dispersed, while the other solution s address only ap-

plication portability between clouds. In relation to the

backgr ound technologies in c louds, just Cloud4SOA

and SeaClouds do not use clouds that have different

backgr ound technologies, that is, all clouds involved

in the portability or interoperability of applications

must have the same background technology for

Cloud4SOA and SeaClouds.

ASMEMA and PaciﬁcClouds solutions are ﬂex-

ible because they allow deploying each application

module in a different cloud, and they enable one mo-

dule to use different technologies than another m o-

dule. Also, it en ables one module to be upda te d in-

dependently of other modules. The difference bet-

ween ASMEMA and PaciﬁcClouds is that the form er

does not do d ecentralized governance by no t tre ating

either interoperability or portability. Therefore, Paci-

ﬁcClouds is the only proposed solutio n that p romo-

tes the decentralized governa nce of the applications,

to th e best of our knowledge, allowing the applica-

tion modules to have a loosely coupled, in addition

to generating less trafﬁc in the network and therefore

allowing greater ﬂexibility.

According to the ana lysis performed in this sub -

section, we can observe that PaciﬁcClouds allows gre-

ater ﬂexibility regard ing interoper a bility in a multi-

cloud environment. Becau se of allowing an applica-

tion to be distributed over several clouds accor ding to

the requirements of the application and the user re-

gardless of the technology used, thro ugh the use of

native cloud application and microservices.

7 CONCLUSION

We show in this work a novel architecture , called Pa-

ciﬁcClouds, that suppor ts the interoperability across

multiple clouds, allowing the software architect to

choose the app lica tion requiremen ts and architecture

with no ne ed to worry about the application de-

ployment in the clouds. Th e architecture also al-

lows the use of several in depend e nt clouds and diffe-

rent technologies backgro unds. Thus, PaciﬁcClouds

achieves another goal of ﬂexibility, which helps more

cloud computing adoption. The PaciﬁcClouds archi-

tecture is based o n microservices to help achieve their

goals. In this manner, PaciﬁcClouds provides othe r

contributions: a) lightweight, since each microservice

has only one function; b) decentralized governance

of the application, because each microservice is in-

dependent of one another, which allows loosely cou-

pled; c) the software architect c an req uest at runtime

a new SLA by analyzing the monitoring metrics; d)

facilitates the use of na tive cloud application in appli-

cation development.

One of the contributions of PaciﬁcClouds is the

ﬂexibility; however, to achieve this, some challenges

need to be overcome. One of the more signiﬁcan t

challenges is to reach the inte roperability of clouds

that possess distinct background technological; in this

manner, sof tware architec ts are prim arily c oncerned

with application development and the user’s SLA. Pa-

ciﬁcClouds must deploy the micro services that com -

pose applications through a deployment plan, and it

must monitor the requirements of the application and

user in runtime, b eyond the capabilities of the clouds.

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

454

In addition, PaciﬁcClouds must build the dece ntrali-

zed g overna nce of the application so tha t the solution

is ﬂexible. Finally, it must allow the app lica tion mi-

croservices to u se distinct technologies.

REFERENCES

Ardagna, D., Nitto, E. D., Milano, P., Petcu, D., Sheri-

dan, C., Ballagny, C., Andria, F. D., and Matthews,

P. (2012). MODAC LOUDS : A Model-Driven Ap-

proach for the Design and Execution of Applications

on Multiple Clouds. Modeling in Software . . . , pages

50–56.

Brogi, A., Fazzolari, M., Ibrahim, A., S oldani, J. , Wang,

P., Informatica, D., Carrasco, J., Cubo, J., Dur, F., Pi-

mentel, E. , Mal, U. D., Ni tto, E . D., Elettronica, D.,

Bioingegneria, I., Milano, P., and Andria, F. D. (2015).

Adaptive management of applications across multiple

clouds : The SeaClouds Approach. 18(1):1–14.

Dandria, F., Bocconi, S., Cruz, J. G., Ahtes, J., and Zeginis,

D. (2012). Cloud4SOA: Multi-cloud application ma-

nagement across paas offerings. Proceedings - 14th

International Symposium on Symbolic and Numeric

Algorithms for Scientiﬁc Computing, SYNASC 2012,

pages 407–414.

Dragoni, N. and Lluch-lafuente, A. (2016). Microservices :

yesterday , today , and tomorrow. (June).

Fehling, C., Leymann, F. , Retter, R. , S chupeck, W., and

Arbitter, P. (2014). Cl oud C omputing Patterns.

Grozev, N. and Buyya, R. (2014). Inter-Cloud architectu-

res and application brokering : taxonomy and survey.

(December 2012):369–390.

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

D., and Tarabanis, K. (2010). Towards a Reference

Architecture for Semantically Interoperable Clouds.

In Cloud Computing Technology and Science (Clou-

dCom), 2010 IEEE Second International Conference

on, pages 143–150.

Mezg´ar, I. and Rauschecker, U. (2014). The challenge of

networked enterprises for cloud computing interope-

rability. Computers in Industry, 65(4):657–674.

Newman, S. (2015). Building Microservices. O ’REILLY.

Nogueira, E., Moreira, A., Lucr´edio, D., Garcia, V., and

Fortes, R. (2016). Issues on developing interoperable

cloud applications: deﬁnitions, concepts, approaches,

requirements, characteristics and evaluation models.

Journal of Software Engineering Research and Deve-

lopment, 4(1):7.

Opara-Martins, J. , Sahandi, R., and Tian, F. (2015). Critical

review of vendor lock-in and its impact on adoption of

cloud computing. International Conference on Infor-

mation Society, i-Society 2014, pages 92–97.

Pautasso, C., Zimmermann, O., Amundsen, M., Lewis, J.,

and Josuttis, N. (2017). Microservices in Practice, Part

1: Reality Check and Service Design. IEE E Software,

34(1):91–98.

Petcu, D. (2013). Multi-Cloud: Expectations and Current

Approaches. In Proceedings of the 2013 International

Workshop on Multi-cloud Applications and Federated

Clouds, MultiCloud ’13, pages 1–6, New York, NY,

USA. ACM.

Petcu, D. (2014a). Consuming Resources and Services

from Multiple Clouds. Journal of Grid Computing,

12(2):321–345.

Petcu, D. (2014b). Portability in Clouds : Approaches

and Research Opportunities, Scalable Computing :

Practice and Experience. 15(3):251–270.

Petcu, D., Macariu, G. , Panica, S., and Craˇciun, C. (2013).

Portable cloud applications - From theory to practice.

Future Generation Computer Systems, 29(6):1417–

1430.

Rezaei, R., Chiew, T. K. , Lee, S. P., and Shams Aliee,

Z. (2014). A semantic interoperability framework

for software as a service systems in cloud compu-

ting environments. Expert Systems with Applications,

41(13):5751–5770.

RV, R. (2016). Spring Microservices. Pack Publishing.

Silva, G. C., Rose, L. M., and Calinescu, R. (2013). A Sy-

stematic Review of Cloud Lock-In Solutions. 2013

IEEE 5th International Conference on Cloud Compu-

ting Technology and Science, pages 363–368.

Sousa, G., Rudametkin, W., and Duchien, L. (2016).

Automated Setup of Multi-Cloud Environments for

Microservices-Based Applications. 9th IEEE Inter-

national Conference on Cloud Computing.

Vaquero, L. M., Rodero-Merino, L., Caceres, J., and Lind-

ner, M. (2009). A break in the clouds. ACM SIG-

COMM Computer Communication Review, 39(1):50.

PaciﬁcClouds: A Flexible MicroServices based Architecture for Interoperability in Multi-Cloud Environments

455