PacificClouds: A Flexible MicroServices based Architecture for
Interoperability in Multi-Cloud Environments
Juliana Oliveira de Carvalho
1,2,3
, Fernando Trinta
1
and Dario Vieira
2
1
Federal University of Cear´a (UFC), Fortaleza, Brazil
2
EFREI-Paris, Paris, France
3
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 benefits, 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 flexibility.
Therefore, we propose PacificClouds, a novel architecture based on microservices for addressing interopera-
bility in a multi-cloud environment. PacificClouds differs from previous works by providing greater flexibility
due to the microservices architectural pattern. In this article, we also propose a definition of microservices
and a comparative analysis of the works related to PacificClouds. Finally, we show the main challenges of
PacificClouds, 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 specific.
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 benefit 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 inflexible; software arc hitects must
adopt specific 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.
PacificClouds: 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
Copyright
c
2019 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
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 definition for microservices.
In this work, we propose a novel architecture ba-
sed on microservices to address interoperability f or a
multi-cloud environment, called PacificClouds, in or-
der to mitigate vendor lock-in and aid to obtain full
cloud advantages. PacificClouds promo tes flexibility
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, PacificClouds 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 flexibility. In Section 4, we pre sent in details
PacificClouds.
PacificClouds is flexible 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 PacificClouds,
a n ovel architecture, which provides greater ease
in the development of native cloud application,
and more flexibility in the deployment and exe-
cution of an application in multiple clou ds envi-
ronment because of m ic roservice use.
A more comprehensive definition of microservic e .
A comparative an a lysis of the works related to Pa-
cificClouds. 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 PacificClouds’ 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 definition s used by (Pe-
tcu, 2014b), who classifies different multiple cloud
application scenarios as delivery models and presents
three main proposals for these models. Th e first, 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-
fits 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).
PacificClouds: A Flexible MicroServices based Architecture for Interoperability in Multi-Cloud Environments
449
3 MICROSERVICES
In the literature, micro services have several definiti-
ons; in this section, we present f our of them and pro-
pose a definition 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 definitio 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 definition 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 definitions 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 definition for microservices based
on the definitions cited in this work, because we un-
derstand that our definition of microservices shows
the meaning of microser vices in the context of multi-
clouds and more specifically in a scen a rio which th e
application is distributed over multiple clouds.
Definition (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 benefits 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 PacificClouds
In order to promote greater adoption of cloud com-
puting, we propose PacificClouds to mitigate vendor
lock-in. PacificClouds is a novel architecture that
addresses the interoperability of distributed ap plica-
tion in multiple clouds via microservices. Thus, Pa-
cificClouds intends to pr ovide flexibility 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, PacificClouds 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 PacificClouds contributions. Next, we
introdu ce and explain the PacificClouds 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 fitness 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 fi-
nances.
AnaGomesFashions virtual fashion store offers a
variety of services such as: thr ee fashion segments
sales service; product fitting 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 PacificClouds Architecture
According to the PacificClouds goals described in
section 1, we adopt the multi-cloud de livery mode l,
for it b rings greater flexibility. 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.
PacificClouds 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,
flexibility. Thus, in th is subsection, we present and
describe the architecture PacificClouds.
In order for architecture to cover all objectives of
PacificClouds, 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, PacificClouds ar-
chitecture consists of three parts: PacificClouds API,
Adapter, pacificClouds Core. The Figure 1 illustra-
tes the PacificClouds architecture; after, we describe
each PacificClouds architecture component.
Figure 1: PacificClouds Architecture.
PacificClouds API is th e communication inter-
face betwe en the software architect and the Paci-
ficClouds Core. The PacificClouds API receives two
artifacts from the sof tware architect: the application
and users’ SLA, which it sends to the PacificClouds
Core. T he PacificClouds Core pr ovides information,
for the sof tware architect via PacificClouds 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 PacificClouds
Core. The adapter sends the capabilities and inform a-
tion about the cloud resources used by the application
to PacificClouds Core. it also sends the microservices
received from the PacificClouds Core to the clouds.
PacificClouds 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 PacificCloud API and it is re-
sponsible for registering it in the AppData (via Ap-
plications Register Service (ARS)) and sending it to
the Microservices Identification 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
profile 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
PacificClouds: 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 Notification Service
Notification Service, shown in Figure 4, is responsib le
for notifying DPGS microservice (via Deployment
Notification 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 notification data in DplNData and notifies the
software architect for deploying or r edeploying of the
application (via User Notification Service (UsrNS)).
Figure 4: The services of the Notification 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 notifica-
tion to Notification 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 notifications received
from Notification 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 identifies 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 PacificClouds 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 PacificClouds 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-
cificClouds must identify eac h of th e services offe-
red by the application, as well as its re quirements. In
addition, PacificClouds 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 PacificClouds 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 PacificClouds 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, configure 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 onfigura 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 lfill 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 specification 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 PacificClouds. For this,
we offer a summary of the features of all the soluti-
ons de scribed in this article, including PacificClouds,
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 flexibility 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
PacificClouds: A Flexible MicroServices based Architecture for Interoperability in Multi-Cloud Environments
453
Table 1: Summary of the characteristics the related work with PacificClouds.
Projects Characteristics
Solutions for Multiple Clouds
Cloud4SOA mOSAIC MODAClouds RASIC ASMEMA SeaClouds PacificClouds
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 PacificClouds
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 PacificClouds 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-
ficClouds 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 PacificClouds solutions are flex-
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 PacificClouds is that the form er
does not do d ecentralized governance by no t tre ating
either interoperability or portability. Therefore, Paci-
ficClouds 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 traffic in the network and therefore
allowing greater flexibility.
According to the ana lysis performed in this sub -
section, we can observe that PacificClouds allows gre-
ater flexibility 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-
cificClouds, 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, PacificClouds
achieves another goal of flexibility, which helps more
cloud computing adoption. The PacificClouds archi-
tecture is based o n microservices to help achieve their
goals. In this manner, PacificClouds 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 PacificClouds is the
flexibility; however, to achieve this, some challenges
need to be overcome. One of the more significan 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-
cificClouds 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, PacificClouds must build the dece ntrali-
zed g overna nce of the application so tha t the solution
is flexible. 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 Scientific 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: definitions, 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.
PacificClouds: A Flexible MicroServices based Architecture for Interoperability in Multi-Cloud Environments
455