Q: Multi-cloud Selection Model based on Multi-criteria to Deploy a

Distributed Microservice-based Application

Juliana Carvalho

, Dario Vieira

and Fernando Trinta

Federal University of Piau

ı (UFPI), Picos, Brazil

EFREI-Paris, Paris, France

Federal University of Cear

a (UFC), Fortaleza, Brazil

Keywords:

Multi-cloud Selection, Microservices, Multi-criteria Decision-making Method.

Abstract:

Choosing the best conﬁguration to deploy a distributed application in a multi-cloud environment is a complex

task since many cloud providers offer several services with different capabilities. In this paper, we present a

multi-cloud selection process to deploy a distributed microservice-based application, which has low commu-

nication cost among microservices. The proposed selection process is part of PaciﬁcClouds, an approach that

intends to manage the deployment and execution of distributed applications across multiple providers from the

software architect perspective. The proposed approach selects various providers, where each provider must

host an entire microservice with multiple tasks consuming several cloud services. The U M

Q approach se-

lects the provider that better meets the software architect requirements, for each microservice of a multi-cloud

application. Hence, the proposed process of selecting multiple providers uses multi-criteria decision-making

methods to rank the cloud services and selects cloud providers and services by individually observing each

microservice requirement, such as cloud availability, response time, and cost. Further, we propose a formal

description of UM

Q and a brief one of the strategy implementation. We also introduce a set of experiments to

evaluate UM

Q performance, and the outcomes showed its feasibility for a variable number of requirements,

microservices and providers, even for extreme values.

1 INTRODUCTION

Nowadays, Cloud Computing has become a very pop-

ular model to provide IT resources. Many cloud com-

panies are widely available to offer several resources

such as virtual servers, storage, and entire applica-

tions to their users. Cloud Computing market is very

competitive, and users have a variety of offerings to

select the service that best ﬁts their requirements. In

contrast, cloud providers try to provide several kinds

of services and resources, leading to a situation where

they became speciﬁc features. This scenario brings a

severe challenge for cloud applications known as ven-

dor lock-in.

A new and more challenging scenario for cloud

application developers is called multi-cloud, where a

single application is composed of resources or ser-

vices hosted by different cloud providers. Multi-cloud

enables developers to build their systems with com-

ponents that better ﬁt their needs, but, it also brings

new challenges. For instance, an application may re-

quire resources available on different cloud providers,

where each resource has different costs, performance,

or availability offers. Hence, multi-cloud brings more

ﬂexibility to software architects where they can select

services for providers that better serve their system

design. However, since these applications are more

complex, using multiple clouds brings challenges for

choosing the best set of resources among the avail-

able ones as there may be several providers offering

many services with the same functionalities, but dif-

ferent capabilities. This scenario makes the process

of selecting the best providers a hard task.

As aforementioned, to facilitate the software ar-

chitects decision-making, Carvalho et al., 2018b pro-

posed PaciﬁcClouds, which is a new approach to

manage the deployment and execution process of an

application based on microservices in multi-cloud en-

vironment from the software architect perspective.

The multi-cloud environment aims to mitigate vendor

lock-in and also allows the software architect to dis-

tribute an application to take the advantages offered

by cloud computing. Also, PaciﬁcClouds uses mi-

croservices as the architectural style because they pro-

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

UM2Q: Multi-cloud Selection Model based on Multi-criteria to Deploy a Distributed Microservice-based Application.

DOI: 10.5220/0009338200560068

In Proceedings of the 10th International Conference on Cloud Computing and Services Science (CLOSER 2020), pages 56-68

ISBN: 978-989-758-424-4

vide support to build applications in which each part

is independently scalable and deployed. To achieve

its goals, PaciﬁcClouds must select the providers and

services to host all application microservices.

A cloud selection process must require several mi-

croservices to build an application, and each of them

needs various cloud services to compose your activ-

ities. Besides, a cloud selection process for Paciﬁc-

Clouds must select among available cloud providers,

which one better meets the needs of the software ar-

chitect and the microservice, observing the function-

alities and requirements of each service required to

compose each microservice. Further, PaciﬁcClouds

must deploy each microservice in a distinct single

cloud provider.

The unlinked microservice mapped to quota

(UM

Q) approach described in this work uses a

multi-criteria decision-making (MCDM) method to

rank all cloud services that meet all requirements in

each provider. Also, UM

Q selects providers observ-

ing each microservice needs regardless of the other

microservices that compose an application. In this pa-

per, we only address applications based on microser-

vices, which have low communication cost among

microservices. We described the entire the proposed

selection process in Section 3. In addition, the ap-

proach proposed in this paper is part of the Paciﬁc-

Cloud project (Carvalho et al., 2018b), which encom-

passes two other approaches to solve the problem of

selecting multiple cloud providers (Carvalho et al.,

2018a), (Carvalho et al., 2019). We compare them

in Section 5.

While our work addresses the multi-cloud selec-

tion process to deploy microservices from the soft-

ware architect’s perspective, there are other works in

the literature that also deal with the cloud selection

problem, but they focus on other issues: some select

services in a single cloud provider, e.g., Chen et al.,

2016 and Hongzhen et al., 2016, while others deal

with the problem using cloud federation, e.g., Thomas

and Chandrasekaran, 2017 and Panda et al., 2018;

some rank cloud services, e.g., Ding et al., 2017 and

Jatoth et al., 2018, and others address the cloud se-

lection to compose services, e.g., Bharath Bhushan

and Pradeep Reddy, 2016 and Mezni and Sellami,

2017; some focus on a trust evaluate, e.g.,Tang et al.,

2017 and Somu et al., 2018, and other works focus

on cloud manufacturing, e.q., Zheng et al., 2016 and

Zhou et al., 2018. In Section 5, we describe and com-

pare some of these research works.

In pursuance of addressing the issues described

above, we propose UM

Q, a multi-cloud selection

process which will be used by PaciﬁcClouds to de-

ploy the application microservices. The main contri-

butions of this work are as follows:

1. UM

Q selects one provider for each application

microservice from the software architect perspec-

tive, in which each provider selects all necessary

cloud services to meet every microservice.

2. We propose a formal description of the selection

process in Subsection 3.1, which describes how to

select each cloud service for each microservice.

3. UM

Q uses a multi-criteria decision-making

(MCDM) method to rank the cloud services in

each available provider and considers the software

architect requirements and its priorities. We de-

scribed the method in Subsection 3.2.

4. In Subsection 3.2, UM

Q selects providers by

individually observing each microservice, which

avoids the need for a global combination of can-

didate services and consequently consumes less

time during providers selection.

5. In Section 4, we performed an evaluation of the

selection process performance and the outcome

shows the feasibility of U M

Q regardless of the

application requirements, number of microser-

vices, and number of providers.

6. We performed a comparison of UM

Q with other

works that address the cloud selection problem

from the software architect perspective. For this,

we proposed Providers and Services Granularity

(PSG), which is a taxonomy to deal with issues

regarding the number of providers in the selection

process, the number of services in each provider,

and the selection process result (Section 5).

2 MOTIVATION

As aforementioned, the primary goal of this work is to

lead the multiple clouds selection process for Paciﬁc-

Clouds. In this section, we show how PaciﬁcClouds

should select multiple clouds for each microservice.

Besides, as PaciﬁcClouds intends to manage the de-

ployment and execution process of an application

based on microservices in multi-cloud, we present

the deﬁnitions of multiple clouds and microservices

adopted in our work.

Figure 1 shows the deployment plan generation

service (DPGS) to PaciﬁcClouds, which is responsi-

ble for selecting the cloud providers and services to

host the microservices. We observe that the cloud

providers selection has three steps: ﬁrst, it receives all

requirements from the SLA service; then, it receives

the cloud providers capabilities from the Adapter; and

ﬁnally, it selects a provider for each microservice

UM2Q: Multi-cloud Selection Model based on Multi-criteria to Deploy a Distributed Microservice-based Application

among the candidate providers that better meets its

requirements through multi-cloud selection service.

For this, it observes a set candidate cloud services

in each provider to optimize the software architect’s

requirements. Each application microservice is de-

ployed in the candidate provider that better meets the

requirements. Finally, it sends the selected providers

to deployment plan generation. Therefore, the use of

the multi-cloud is very important to allow each mi-

croservice to ﬁnd the best offer according to its re-

quirements, and to mitigate vendor lock-in. The se-

lection approach has three levels. The ﬁrst one selects

the required cloud services for each microservice in

each provider. The second one selects the candidate

combinations to compose each microservice in each

provider. The third one selects a provider among can-

didate providers for each microservice.

Figure 1: The multi-cloud Selection by PaciﬁcClouds.

We adopt the deﬁnition of the multi-cloud used by

Petcu, 2014, who classiﬁes different multiple cloud

application scenarios as delivery models. One of them

is multi-cloud, in which the services can be used

in parallel or sequentially, and it does not include a

prior agreement among the cloud providers and a third

party acts as a mediator. We also adopt the deﬁni-

tion of microservices used by Carvalho et al., 2018b,

where a microservice is a set of autonomous, indepen-

dent, self-contained services, in which each service

has a single goal, is loosely coupled, and interacts to

build a distributed application. Microservices repre-

sent an application business function.

3 THE SELECTION MODEL

According to Section 2, we can notice that there may

be many available cloud providers, and each of them

offers several services. Also, an application can have

several microservices, and each one of them may re-

quire several cloud services to meet the microservices

tasks needs. Therefore, the task of selecting cloud

providers to host a distributed application in multiple

clouds is complex.

In this section, we propose a multi-cloud selection

model for PaciﬁcClouds to host an application based

on microservices called UM

Q. The proposed selec-

tion model refers to the cloud providers selection from

the software architect’s perspective before an applica-

tion deployment. The proposed selection process is

based on the software architect requirements. Thus,

the software architects must deﬁne their requirements

for an application. Also, the software architects must

set a budget’ quota for each application microservice.

We consider that the provider’s capabilities are avail-

able. Even though our approach can handle as many

requirements as needed, in this paper, we consider

three user requirements: (i) response time, (ii) avail-

ability, and (iii) application execution cost.

3.1 Formulation

As mentioned above, the required cloud services to

compose a microservice have different requirements

and the providers offer many services with the same

functionalities but different capabilities. In this work,

we choose to assess application response time (exe-

cution time + delay), cloud availability and applica-

tion execution cost, but other requirements can be in-

cluded in our model. We use three user requirements

that are sufﬁcient to understand the proposed selec-

tion process. However, the software architect can de-

ﬁne several other user requirements without signiﬁ-

cant changes in the code.

According to the providers selection process pre-

viously described, we propose:

• Deﬁnition 1: Cloud Service Model - as

S(S.rt,S.a,S.c), in which S.rt, S.a, and S.c stand

for response time, availability, and cost, respec-

tively, as in (Liu et al., 2011).

• Deﬁnition 2: Cloud Services Class - as SC

, S

, . . . , S

}, in which S

, S

, . . . , S

are

services of the same provider with same function-

alities but different capabilities.

• Deﬁnition 3: Services Provider Model - as SP

{SC

, SC

, . . . , SC

}, in which SC

, SC

, . . . ,

are services classes.

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

• Deﬁnition 4: Cloud Provider Set - as CP = {SP

, . . . , SP

}, in which SP

, SP

, . . . , SP

are

services providers.

• Deﬁnition 5: Microservice Model - as MS

, S

, . . . , S

}, in which S

, S

, . . . , S

are cloud services indispensable to execute a mi-

croservice, and they should be of different cloud

service classes. Each service required to com-

pose the microservice i can belong to different

classes of services from a cloud provider. Thus,

1 6 k

6 o, in which o is the maximum number of

classes for a cloud provider.

• Deﬁnition 6: Application Model - as AP =

{MS

, MS

, . . . , MS

}, in which MS

, MS

, . . . ,

are microservices.

The main goal of the multi-cloud selection process

is to select the providers that satisfy software archi-

tects requirements and optimize their speciﬁed objec-

tives, as follows:

3.1.1 Availability Requirement

The cloud availability for an application must meet

at least the user-deﬁned threshold, so that each ap-

plication microservice meets the same threshold. We

deﬁne MinAvbty as the user-deﬁned minimum avail-

ability threshold. In Eq. 1, we deﬁne AP.a as the

application availability, which is assigned the low-

est availability value among its microservices, and it

must be greater than or equal to MinAvbty. In ad-

dition, in Eq. 2, MS

.a represents the microservice

availability i, which is assigned the lowest availabil-

ity value among their services and it must be greater

than or equal to MinAvbty. The cloud availability for

a service is represented by S

i j

.a in Eq. 2, which is

the service j of the microservice i.

AP.a = min

16i6t

(MS

.a) > MinAvbty, ∀MS

| MS

∈ AP

(1)

.a = min

16 j6r

i j

.a) > MinAvbty,

∀S

i j

| S

i j

∈ MS

, MS

∈ AP, 1 6 i 6 t

(2)

3.1.2 Response Time Requirement

The response time for an application must meet the

user-deﬁned threshold, so that each application mi-

croservice meets the same threshold. We deﬁne

MaxRT as the user-deﬁned maximum response time

threshold, and MaxRT is the maximum execution time

threshold (MaxExecTime) plus the maximum delay

threshold (MaxDelay) deﬁned by the user, as in Eq.

3. In Eq. 4, we deﬁne AP.rt as the response time

of the application, which is assigned the highest re-

sponse time value among their microservices, and that

must be less than or equal to MaxRT. In addition, in Eq.

5, MS

.rt represents the response time of microservice

i, which is assigned the highest response time value

among their services and that must not be less than

MaxRT. The response time for a service is represented

by S

i j

.rt in Eq. 5, which is the service j of the mi-

croservice i.

MaxRT = MaxExecTime + MaxDelay

(3)

AP.rt = max

16i6t

(MS

.rt) 6 MaxRT, ∀MS

| MS

∈ AP

(4)

.rt = max

16 j6r

i j

.rt) 6 MaxRT,

∀S

i j

| S

i j

∈ MS

, MS

∈ AP, 1 6 i 6 t

(5)

3.1.3 Cost Requirement

The application execution cost should not be higher

than the cost threshold deﬁned by the user (Budget).

In Eq. 6, we deﬁne AP.c as the application execution

cost, which is assigned as the sum of all its microser-

vices’s costs, and that must be less than or equal to the

provided Budget.

AP.c =

∑

i=1

.c 6 Budget, ∀MS

| MS

∈ AP (6)

In this work, an application has t as the microser-

vices maximum, and a microservice has r as the ser-

vices maximum. We do not address the services capa-

bilities model from the provider perspective because

this work focuses on the software architect perspec-

tive. We only verify if the service capabilities offered

by a cloud provider meet the user requirement.

3.2 UM

Q Selection Process

In UM

Q, we select multi-cloud providers to host

each microservice of an application and each mi-

croservice is hosted by a single provider, consider-

ing only the microservice and software architect re-

quirements. Each microservice is hosted in a single

provider for it to have a low cost of communication

between services from different providers. This ap-

proach presents three selection levels, which will be

described next.

UM2Q: Multi-cloud Selection Model based on Multi-criteria to Deploy a Distributed Microservice-based Application

3.2.1 First Level

We select the services of each provider that meet

all software architect requirements which results in

a candidate services set for each provider. Next, we

rank all candidate services in each provider. We use

Simple Additive Weighting (SAW) technique as in

(Seghir and Khababa, 2016), which has two phases:

scaling and weighting.

Scaling Phase. First, a matrix R = (R

i j

;1 6 i 6

n;1 6 j 6 3) is built by merging the requirement vec-

tors of all candidate services. For this, the user re-

quirements are numbered from 1 to 3, with 1 = avail-

ability, 2 = response time, 3 = cost. These candidate

services refer to the same service of the microservice.

We must perform the entire process for each service

of the microservice. Each row R

corresponds to a

cloud service S

i j

and each column R

corresponds to a

requirement. Next, the requirements should be ranked

using one of the two criteria described in Eqs. 7 and 8.

Also, R

Max

= Max(R

i j

), R

Min

= Min(R

i j

), 1 6 i 6 n.

Negative: the higher the value, the lower the quality.

i j







Max

−R

i j

Max

−R

Min

if R

Max

− R

Min

6= 0

1 if R

Max

− R

Min

= 0

(7)

Positive: the higher the value, the higher the quality.

i j







i j

−R

Min

Max

−R

Min

if R

Max

− R

Min

6= 0

1 if R

Max

− R

Min

= 0

(8)

Weighting Phase. The overall requirements score

is computed for each candidate cloud service (Eq. 9).

Score(S

) =

∑

j=1

i j

∗W

) | W

∈ [0, 1],

∑

j=1

= 1 (9)

At the end of the ﬁrst level, we have a set of all

candidate services for each microservice in all avail-

able providers.

3.2.2 Second Level

We must select all required services to compose each

microservice in each provider from the candidate ser-

vices selected in the ﬁrst level. For this, we consider

that the software architects deﬁne a budget quota for

each microservice of an application. Thus, in Eq. 10,

we deﬁne MS

.c as the microservice execution cost,

which must be less than or equal to (Budget ∗Quota

We deﬁne Quota

as the application execution budget

quota deﬁned for microservice i, and Budget as the

application execution cost threshold. Next, in Eq. 11,

we deﬁne that each Quota

must be between 0 and 1

and that the value sum of all (Budget ∗ Quota

) must

be equal to the Budget. In addition, in Eq. 12, we de-

ﬁne that the cost sum of all services of microservice

i must be less than or equal to the execution cost of

microservice i.

.c 6 Budget ∗ Quota

, ∀MS

| MS

∈ AP (10)

Quota

∈]0, 1],

∑

i=1

Budget ∗ Quota

= Budget (11)

∑

j=1

i j

.c 6 Budget ∗Quota

, ∀S

i j

| S

i j

∈ MS

, 1 6 i 6 t

(12)

In order to compose a microservice, we need to

combine all candidate services and check the execu-

tion cost for these services combinations. First, we

must combine the candidate services that come from

the same microservice and are offered by the same

provider, which is represented by (S

i j

, ..., S

i j

) in Eq.

13. Each element of the candidate combination S

i j

represents the candidate service j of provider k to the

microservice i, in which 1 6 j 6 r and r indicates the

number of services to microservice i. Next, we cal-

culate the combination execution cost and verify if it

is less than or equal to (Budget ∗ Quota

) as shown in

Eq. 13, which is in accordance to Eqs. 10, 11, and 12.

Each microservice has a maximum r services.

, ..., S

) | (S

.c + ... + S

.c) 6 Budget ∗ Quota

(13)

Next, we must choose a combination among can-

didate services combinations in each provider for

each microservice. For this, it calculates the average

score for each services combination, which is rep-

resented by aSC

in Eq. 14. SP

is the provider

k that belongs to a set of providers (CP), and CP

has a maximum q providers. Besides, Score(S

) +

Score(S

)+ ... + Score(S

) represents the sum of all

service scores of a combination, S

is a candidate ser-

vice of a combination, and r is a maximum of mi-

croservice services. We must choose the combination

with the highest score average.

aSC

Score(S

) + Score(S

) + ... + Score(S

)

(14)

If multiple combinations have the highest score

average, one of them must be selected based on one

of the three requirements according to the priorities

deﬁned by a software architect.

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

At the end of the second level, there must be a

candidate provider set (CSP

) for each MS

of an ap-

plication as shown in eq. 15. SP

represents the can-

didate provider k of microservice i, and it has a candi-

date service combination chosen for a microservice i.

An application has a maximum t microservices, and a

microservice has a maximum q

candidate providers.

CSP

= {SP

, SP

, . . . , SP

} | 1 6 i 6 t,

t = sizeo f (AP), q

= sizeo f (CSP

)

(15)

3.2.3 Third Level

We select one provider for each microservice. First,

we check the microservice execution cost for each

candidate provider, which was calculated in the sec-

ond level, as shown in Eq. 16. In this equation,

.c indicates the execution cost of the microservice

i for candidate provider k. We deﬁne that SP

.c is

the service costs sum of the candidate combination of

provider k. In Eq. 16, S

i j

.c is the service j cost of

microservice i in candidate provider k.

.c =

∑

j=1

i j

.c) | S

i j

∈ SP

, SP

∈ CSP

1 6 k 6 q

, 1 6 i 6 t

(16)

Next, we check the CSP from the Second Level

for each microservice to obtain the SP that presents

the average microservice execution cost, and we use

Eqs. 17, 18 and 19. In Eq. 17, Max(MS

.c) returns the

highest microservice execution cost among the candi-

date providers for microservice i. Next, in Eq. 18,

Min(MS

.c) returns the lowest microservice execution

cost among the candidate providers for microservice

i. In addition, in Eq. 19, Average(MS

.c) returns the

average microservice execution cost among the can-

didate providers for microservice i.

Max(MS

.c) = max

16k6s

(SP

.c) | ∀SP

∈ CSP

1 6 i 6 t, q

= sizeo f (CSP

)

(17)

Min(MS

.c) = min

16k6s

(SP

.c) | ∀SP

∈ CSP

1 6 i 6 t, q

= sizeo f (CSP

)

(18)

Average(MS

.c) =

Max(MS

.c) + Min(MS

.c)

(19)

In case there is more than one provider with the

same average execution cost, we select the provider

that presents the highest availability or performance,

observing the priority deﬁned by a user. For this, we

use Eqs. 20 and 21 to calculate the availability and re-

sponse time for each candidate provider, respectively.

Equation 20 deﬁnes SP

.a as the cloud availability of

provider k for microservice i, which is assigned the

lowest candidate service availability for microservice

i. Equation 21 deﬁnes SP

.rt as the response time of

provider k for microservice i, which is assigned the

highest candidate service response time of microser-

vice i. Next, we use Eqs. 22 and 23 to calculate

the highest value for availability and the lowest value

for response time in each candidate provider based on

Eqs. 20 and 21, respectively.

.a = min

16 j6r

i j

.a) | S

i j

∈ SP

, SP

∈ CSP

1 6 k 6 q

, 1 6 i 6 t

(20)

.rt = max

16 j

i j

.rt) | S

i j

∈ SP

, SP

∈ CSP

1 6 k 6 q

, 1 6 i 6 t

(21)

Max(MS

.a) = max

16k6s

(SP

.a) | ∀SP

∈ CSP

(22)

Max(MS

.rt) = min

16k6s

(SP

.rt) | ∀SP

∈ CSP

(23)

3.3 Diagram and Algorithm

In this subsection, we present a diagram and describe

an algorithm for UM

Q, which are illustrated in Fig-

ure 2 and Algorithm 1, respectively. Figure 2 shows

an overview of each level described in Subsection

3.2 to the multi-cloud selection process. Algorithm

1 presents the pseudocode with more detail of every

level of our approach.

The diagram in Figure 2 starts with a set of avail-

able cloud providers and a set of application microser-

vices, and it has three parts representing each level of

our approach. It shows two tasks in this ﬁrst part:

the ﬁrst one discovers every candidate service for a

microservice in a cloud provider, and the second one

ranks all candidate services.

The second part of the diagram shows four tasks,

which aim to build all the candidate combinations

for a microservice in all available cloud providers.

First, it makes all candidate combinations in a single

provider. A candidate combination is composed of all

necessary services for a microservice, and the combi-

nation cost is lower than or equal to Budget’s quota.

Next, it calculates the combination score and selects

the combination with the highest score. If there is

UM2Q: Multi-cloud Selection Model based on Multi-criteria to Deploy a Distributed Microservice-based Application

more than one combination with the highest score,

then it chooses the combination that has the highest

priority. The entire process is repeated for all avail-

able providers.

The third diagram part in Figure 2 presents four

tasks, which aim to select a cloud provider combi-

nation for each microservice. In the ﬁrst and second

tasks, it calculates the combination cost and selects

the combination with the average cost. If there is

more than one combination with the average cost, it

selects the combination with the highest priority. The

whole process is repeated for all microservices of an

application. Finally, it returns a set of combinations,

in which each combination represents a microservice.

Figure 2: Diagram for UM

Next, we describe Algorithm 1, which is based on

Figure 2. It has two inputs: the set of application re-

quirements and the set of cloud providers capabilities;

and one output: the set of the providers to host all ap-

plication microservices.

To achieve the goals of our approach, Algorithm

1, in line 6, discovers the candidate services in a sin-

gle provider, in which a candidate service is a cloud

service that meets all requirements for a microservice.

Next, in lines 8 and 9, it ranks the candidate services,

according to Eqs. 7, 8, and 9. After, in line 10, it

combines all candidate services necessary to compose

a microservice in a manner that the combination cost

is lower than or equal to the microservice quota in ac-

cordance to Eqs. 10, 11, 12, and 16. Then, in line

11, it adds all candidate combinations of a provider to

the candidate combinations list for a microservice. It

calculates the combination score in accordance to Eq.

14 between lines 13 and 17. It returns the combina-

tion with the highest score in line 19, next, it checks

if there is more than one combination with the high-

est score between lines 20 and 24. In case this hap-

pens, it checks which of these combinations has the

highest priority, according to user preferences. The

entire process is repeated in every available provider

for the same microservice. Hence, at the end of this

level, it has a set of combinations for a microservice,

being one of each candidate cloud provider. A can-

didate cloud provider is a cloud provider that has at

least one candidate services combination to compose

a microservice.

Note that in line 29, to achieve the third level, Al-

gorithm 1 calculates the average combination cost ac-

cording to Eqs. 17, 18, and 19. Next, in line 30, it

veriﬁes the combinations that have the average cost.

In lines 31 and 32, if there is more than one combi-

nation with the average cost, it checks which combi-

nation has the greatest score in line 32. If there is

more than one combination with the highest score in

line 34, it gets the combination with the highest pri-

ority according to user preferences. Thus, at the end

of this level, it has a combination of a provider to host

a microservice. The entire process is repeated for all

microservices of an application. It returns a set of

combination, which is composed of a combination for

each microservice.

4 EVALUATION

In this work, we evaluate the UM

Q process perfor-

mance. First, we set up the scenarios that allow us to

check UM

Q behavior so that it is the same for the

other scenarios. Next, we developed a tool to eval-

uate U M

Q feasibility. In this section, we describe

the scenarios conﬁguration, the tool, the experiments,

and the outcomes.

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

Algorithm 1: The Algorithm for UM

input : Set of the application requirements ap

Set of the capabilities of the providers

output : Set of Providers prvdsMs to host each

application microservice

1 foreach ms of the ap do

2 combLtPr ← initialize with empty set;

3 combsMS ← initialize with empty set;

4 combListMS ← initialize with empty set;

5 foreach sp of the cp do

6 candServ ← discoveryCandServ (ms, sp);

7 if (not empty(candServ)) then

8 matReq ← sawScalPh (candSr);

9 candSrSC ← sawSCPh (candSr, matReq,

ap.wgt);

10 combsMS ← combsMS + combMsSp

(candSrSC, quotaMS);

11 combLtPr ← combLtPr + (sp.number,

combsMS);

12 end

13 combLtPrSC ← initialize with empty set;

14 foreach comb of the combLtPr do

15 combSC ← calculateCombSC (comb);

16 combLtPrSC ← combLtPrSC + (comb,

combSC);

17 end

18 combLtPrHg ← initialize with empty set;

19 combLtPrHg ← combLtPrHg + combHgtSC

(combLtPrSC);

20 if (not empty(combLtPrHg)) then

21 if (sizeof(combLtPrHg) > 1) then

22 combPrMS ← combHgtPrty

(combLtPrHg, prty);

23 end

24 end

25 combLtMS ← combLtMS + combPrMS;

26 end

27 if (not empty(combLtMS)) then

28 if (sizeof(combLtMS) > 1) then

29 avgCost ← averageCost (combLtMS);

30 combLtMSAgCost ← combAvgCost

(combLtMS, avgCost);

31 if (sizeof(combLtMSAgCost) > 1) then

32 ﬁnalCbMS ← ﬁnalCbMS +

combHgtSC (combLtMS);

33 if (sizeof(ﬁnalCbMS) > 1) then

34 ﬁnalCbMS ← combHgtPrty

(combLtMS, prty);

35 end

36 end

37 end

38 end

39 combFinalLt ← combFinalLt + (ms.number,

ﬁnalCbMS);

40 end

41 return combLtFinal

4.1 Tool Description

We developed a tool to evaluate the UM

Q selection

process. The tool was implemented using Python 3.7,

and we used the JSON format as input and output.

The tool has two JSON ﬁles as input: one contains

the service providers capabilities; the other has the

application requirements. Each provider capability is

organized by service classes and each class has its ser-

vices. We consider three classes: computing, storage,

and database. Each service must contain its functional

and non-functional capabilities. As described in Sec-

tion 3, UM

Q considers availability, response time,

and cost as nonfunctional capabilities.

Application information involves name, minimum

availability, maximum response time, maximum bud-

get, weight and priority of each user requirement,

which are the same for each microservice. Besides, an

application also contains microservice information,

and there must be a description of the name and the

total budget quota as in Eq. 10. The tool returns a

JSON ﬁle, which contains the providers that will host

the microservices as well as the services that will be

used and each providers’ cost.

4.2 Setting Scenarios

According to Hayyolalam and Pourhaji Kazem, 2018,

there are few available datasets in the research do-

main. In this manner, in ﬁfty percent of the works

referenced by Hayyolalam et al, the authros use a

dataset conﬁgured randomly. We also randomly con-

ﬁgured ten sets of providers, which differ from one

another by the number of providers and service ca-

pabilities. Each provider has three services classes:

compute, storage, and database; each class has seven

services. The amount of providers in each set is a

multiple value of 100, in which the ﬁrst set has 100

providers and the last 1000.

Also, we conﬁgured the requirements for

microservices-based applications. We conﬁgured ﬁve

applications: the ﬁrst one (APP1) has 6 microser-

vices, the second (APP2) 9, the third (APP3) 12,

the fourth (APP4) 15, and the last one (APP5) has

18 microservices. Each microservice contains one

service of each class: compute, storage, and database.

Availability, response time, and cost requirements

vary depending on the type of assessment that should

be performed.

4.3 Experiments and Outcomes

We evaluated the performance of UM

Q using our

tool described in 4.1. For this, we performed ﬁve ex-

UM2Q: Multi-cloud Selection Model based on Multi-criteria to Deploy a Distributed Microservice-based Application

periments, and used the scenarios, according to Sub-

section 4.2, which described 10 sets of providers and

the requisites of 5 applications. Each experiment was

performed 30 times to reach the normal distribution

(Hogendijk and Whiteside, 2011).

In all ﬁve experiments, the y-axis represents the

average selection time in milliseconds (ms), the rows

represent the applications, and the x-axis shows each

experiment. The ﬁrst experiment uses the ten provider

sets described in Section 4.2, illustrated by Figure

3. Availability, response time, and cost requirements

were not modiﬁed during the experiment, maintain-

ing the same value across all sets. Figure 3 shows

that increasing the number of providers inﬂuences the

average selection time as it increases the number of

services that meet application requirements. Also, we

can observe that the number of microservices also af-

fects the average selection time of providers.

Figure 3: The Set of Providers Experiment.

Figure 4 presents the other four experiments,

which were performed using a set of 1000 providers,

and each application was set to 5 different values

(Figure 4a). The lowest one, 90%, indicates that all

provider services must have this minimum value to

meet application requirements, and the highest one,

98%, indicates that only cloud services with values

between 98 and 100 meet this application require-

ment, which is in agreement with Eqs. 1 and 2. We

set response time and cost requirements to values that

can be met by most providers. The results show that

the average time decreases with increasing availabil-

ity requirement value in each application.

Figure 4b shows the experiment in which we con-

ﬁgured each application with ﬁve response time val-

ues. Thus, the lower the response time value, the

fewer the cloud services meet the requirement. We

set availability and cost requirements to values that

can be achieved by most providers. The graph in Fig-

ure 4b shows the selection time increases with the in-

crease of the response time requirement in every ap-

plication. We created budget classes for the experi-

ment in Figure 4c, in which each class has different

budget values for each application, but all applica-

tions have the same value per service in each class.

The results show that the average selection time in-

creases as the budget class increases. After a certain

amount, the average selection time is stabilized, be-

cause the ceiling has been reached and even if the bud-

get increases, the number of services to be selected

will not increase.

Figure 4d shows the experiment in which we vary

the three requirements, in a manner that when the

availability requirement increases, the cost and re-

sponse time requirements decrease. We can observe

that the average selection time in the Figure 4d de-

creases with the requirements restriction increase.

This outcome shows that the requirements restriction

increase reduces the number of providers that meet all

requirements and that the average selection time tends

to stabilize because the budget value is higher than the

cloud cost value.

5 RELATED WORK

Several works address the cloud selection problem,

but each of them worries about different issues be-

cause there are several open ones. In this work, we

describe some research works that lead with the se-

lection problem from the user perspective. For this,

we describe a summary of these works characteris-

tics in Table 1, which contains seven columns. The

ﬁrst column presents the work reference. The sec-

ond, third, and fourth columns refer to a taxonomy

to identify the work focus that deals with the cloud

providers selection regarding the number of providers

and services used by them in each phase, which we

named providers and services granularity (PSG). The

second column shows the number of providers in the

selection process, the third one shows the number of

selected providers, and the fourth one indicates the

granularity per selected provider. Furthermore, the

ﬁfth column presents the methods used to solve the

selection problem, the sixth one shows whether or not

the user deﬁnes the requirements threshold, and in the

last one presents the goals of the work. In Table 1,

n indicates the number of providers in the selection

process, which must be greater than 1; while, m indi-

cates the number of selected providers and it must be

greater than 1 and lower than or equal to n.

Note in Table 1 that the ﬁrst four works use a sin-

gle cloud provider and address the service composi-

tion problem. Chen et al., 2016, in the ﬁrst table

line, studied dependency-aware service composition

considering multiple QoS attribute to maximize the

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

(a) Availability. (b) Response Time.

Figure 4: Experiments for UM

proﬁt but they did not discover the services. While

Hongzhen et al., 2016, in the second table line, pro-

posed a strategy of cloud service composition evo-

lution based on QoS, and the QoS values are calcu-

lated based on a four-structure model. Liu et al., 2016

proposed an approach for QoS-aware cloud service

compostion that allows the user to deﬁne the QoS

constraints and its preferences. Since microservices

are composed of various services, we can consider

them as a service composition. Therefore, UM

differs from the Liu et al., 2016 because we ad-

dress several service composition in parallel, one for

each microservice, and we select a service composi-

tion among every service composition of all available

providers to host a microservice. In the fourth table

line, Seghir and Khababa, 2016 also address QoS-

aware cloud service, and this work differs both from

the Liu et al., 2016 and UM

Q because of the method

used to solve the problem.

We can observe in the ﬁfth and sixth table lines,

that the works of Ding et al., 2017 and Jatoth et al.,

2018 address the service ranking. They differ from

one another by the method used to rank the services.

Besides, they differ from UM

Q because they do not

select various services in multiple providers. In the

seventh and eighth table lines, Thomas and Chan-

drasekaran, 2017 and Panda et al., 2018 use cloud

federation to execute a user requisition that cannot be

executed for selected providers, which makes them

only use multiple clouds when necessary.

Lastly, in the ninth, tenth, and eleventh table lines,

Sousa et al., 2016, Bharath Bhushan and Pradeep

Reddy, 2016, and Mezni and Sellami, 2017 use mul-

tiple clouds in both the selection and run-time pro-

cesses as U M

Q, but they select services over var-

ious clouds while U M

Q selects microservices. In

addition, these works do not allow the user to deﬁne

the requirements thresholds. Further, UM

Q is more

complex and more ﬂexible, and it has a low commu-

nication cost because microservices are independent.

Besides, this paper is part of the PaciﬁcCloud

project (Carvalho et al., 2018b), which addresses

the selection of cloud providers in multi-cloud envi-

ronments, where native cloud applications are com-

posed of components/modules hosted on different

cloud providers/services. In multi-cloud scenarios,

choosing an optimal conﬁguration for each applica-

tion component is challenging once we should con-

sidered several requirements, such as performance,

availability, or even ﬁnancial costs. We can point

out that these requirements act as selection criteria,

and the native cloud applications have their multi-

ple functionalities provided by independent microser-

vices. We investigated different approaches to select

UM2Q: Multi-cloud Selection Model based on Multi-criteria to Deploy a Distributed Microservice-based Application

Table 1: Summary of the related work characteristics.

Characteristics

Related Work

PSG Method

user-deﬁned

Threshold

Goals

(1) (2) (3)

(Chen et al., 2016) 1 1

Service

Composition

Pareto set model,

vector Ordinal

Optimization

QoS dependency-aware

service composition

considering multiple

QoS atribute

(Hongzhen et al., 2016) 1 1

Service

Composition

Hybrid particle

swarm

cloud service composi-

tion evolution

(Liu et al., 2016) 1 1

Service

Composition

SLO yes

Sequential cloud ser-

vice composition

(Seghir and Khababa,

2016)

1 1

Service

Composition

Hybrid GA yes

QoS-aware cloud ser-

vice composition

(Ding et al., 2017) n 1 Service CSRP no

Ranking of top-k simi-

lar Service

(Jatoth et al., 2018) n 1 Service

Grey Technique,

TOPSIS, AHP

no Ranking of Service

(Thomas and Chan-

drasekaran, 2017)

n m Resources TOPSIS, AHP no

Selection of cloud fed-

eration provider to exe-

cute a user requisition

(Panda et al., 2018) n m Tasks

Deﬁned by Au-

thors

Independent task

scheduling in cloud

federation

(Sousa et al., 2016) n m Service

Deﬁned by Au-

thors

Selection and conﬁg-

uration of multi-cloud

for microservices-

based applications

(Bharath Bhushan and

Pradeep Reddy, 2016)

n m Service PROMETHEE no

Selection QoS aware

services for a service

Composition

(Mezni and Sellami,

2017)

n m Service FCA no

Service composition in

multi-cloud that focus

on the communication

cost

n m Microservices

SAW, Deﬁned by

Authors

yes

Multi-cloud selection

to host the application

microservices

PSG-Providers and Services Granularity, (1) Provider Granularity in the Selection Process, (2) Provider Granularity in the

Selection Result, (3) Service Granularity per Provider.

the best set of cloud providers to host each one of the

applications’ microservices according to software ar-

chitects’ requirements.

The ﬁrst approach uses dynamic programming in

(Carvalho et al., 2018a) and the second ones uses a

greedy algorithm in (Carvalho et al., 2019). Finally,

in this paper we propose a new approach that uses a

multi-criteria strategy where each of the cloud archi-

tect provides budget quotas for a set of application

microservices. In addition, these quotas must be hon-

ored when selecting the available cloud providers.

These three papers follow the same methodology.

We established a set of scenarios where we change

a set of parameters including (i) the number of mi-

croservices that represents each application, (ii) the

requirements of each microservice, (iii) the number

of available cloud providers or (iv) the number of

services offered by each cloud provider. We then

checked the overall performance of each solution ac-

cording to several parameters conﬁguration. In addi-

tion, all three papers have one similarity: a software

architect must deﬁne boundary values for three ap-

plication properties: availability, response time, and

expected budget. The software architect also deﬁnes

weights among these attributes according to the ap-

plication priorities (for instance, response time may

be more important than availability). The solutions in

these articles should select the combinations of ser-

vices among the available cloud providers that best

meet the application’s microservices. For each com-

bination, we compute a score according to the soft-

ware architect’s requirements. However, the proposed

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

approach differs from the previous ones as following:

• Instead of setting a global budget quota for the

entire application, in the proposed approach, we

adopt another strategy where each microservice

has its own budget. Once the budget quota is not a

global requirement for the whole application any-

more, the selection of the best cloud provider for a

single microservice depends only on the selection

of candidates to host the microservices of each

application. This new strategy allows us to ﬁlter

cloud providers that do not ﬁt the microservices

budget independently of any global procedure. It

also decreases the search space among the cloud

providers, which results in faster responses in the

selection process.

• The solutions proposed in Carvalho et al., 2018a

and Carvalho et al., 2019 are mapped into the

multi-choice knapsack problem and then imple-

mented using a dynamic algorithm and a greedy

algorithm, respectively. Both strategies impose an

interdependence among the application microser-

vices. the proposed approach does not follow

these strategies since a provider is selected for

each microservice independently from the other

microservices (Sections 3.2 and 3.3). In this

way, algorithms in the three approaches are dif-

ferent and share different scenario sizes. The ap-

proach that uses a dynamic algorithm imposes

limits in the size of the entry (number of microser-

vices in the application and number of available

providers), but always selects the best solution

(Section 3 in Carvalho et al., 2018a). The greedy

algorithm version accepts a larger input and se-

lects a viable solution, but not necessarily the best

one (Section III in Carvalho et al., 2019). Never-

theless, the proposed approach accepts large en-

tries and provides the best solution for each mi-

croservice based on the deﬁnition of the budget

quota for each microservice deﬁned by the soft-

ware architect (Section 4).

6 CONCLUSION

Multi-cloud has stirred the interest of both the

academy and the industry to mitigate vendor lock-in

as well as to proﬁt from the advantages offered by

cloud computing. One of the challenges is that many

cloud providers offer many services with the same

functionality but with different capabilities, turning

the provider selection into a complex task.

PaciﬁcClouds aims to manage the deployment and

execution of the microservice-based applications in

multi-cloud environments. For this, PaciﬁcClouds

needs to select providers to host the application mi-

croservices. Therefore, in this work we propose

Q to select cloud providers to host microser-

vices. The outcomes obtained in the experiments

show that the application requirements, the num-

ber of application microservices and the number of

providers inﬂuence the provider’s selection time. The

results also indicate UM

Q viability, since the selec-

tion time was satisfactory in any scenario, even for

extreme values.

One limitation of the UM

Q is the difﬁculty of

the software architect to determine a budget quota for

each microservice of an application. Another limi-

tation of UM

Q is that it is speciﬁc to applications

based on microservices that have low communication

costs. In regards to these limitation, as future work,

we intend to investigate two possible solutions. One

to develop a selection process in which the user does

not have to determine a budget quota for each mi-

croservice and compare the two approaches, and an-

other in the monitoring phase, in which the microser-

vices are already deployed, verifying the expenses for

each microservice, resizing the quotas when needed

and making a new providers selection to migrate the

microservices involved in this process.

In addition, as future work, we intend to imple-

ment a recommendation system to suggest better set-

tings than those requested by the user, which would

be available with a little more investment.

REFERENCES

Bharath Bhushan, S. and Pradeep Reddy, C. H. (2016).

A Qos aware cloud service composition algorithm

for geo-distributed multi cloud domain. Interna-

tional Journal of Intelligent Engineering and Systems,

9(4):147–156.

Carvalho, J., Vieira, D., and Trinta, F. (2018a). Dynamic

Selecting Approach for Multi-cloud Providers. In

Luo, M. and Zhang, L.-J., editors, Cloud Computing –

CLOUD 2018, pages 37–51, Cham. Springer Interna-

tional Publishing.

Carvalho, J., Vieira, D., and Trinta, F. (2019). Greedy

Multi-cloud Selection Approach to Deploy an Appli-

cation Based on Microservices. In PDP 2019.

Carvalho, J. O. D., Trinta, F., and Vieira, D. (2018b). Paci-

ﬁcClouds : A Flexible MicroServices based Archi-

tecture for Interoperability in Multi-Cloud Environ-

ments. In CLOSER 2018.

Chen, Y., Huang, J., Lin, C., and Shen, X. (2016). Multi-

Objective Service Composition with QoS Depen-

dencies. IEEE Transactions on Cloud Computing,

7161(c):1–1.

UM2Q: Multi-cloud Selection Model based on Multi-criteria to Deploy a Distributed Microservice-based Application

Ding, S., Wang, Z., Wu, D., and Olson, D. L. (2017). Uti-

lizing customer satisfaction in ranking prediction for

personalized cloud service selection. Decision Sup-

port Systems, 93:1–10.

Hayyolalam, V. and Pourhaji Kazem, A. A. (2018).

A systematic literature review on QoS-aware ser-

vice composition and selection in cloud environ-

ment. Journal of Network and Computer Applications,

110(February):52–74.

Hogendijk, J. and Whiteside, a. E. S. D. (2011). Sources and

Studies in the History of Mathematics and Physical

Sciences. Springer US.

Hongzhen, X., Limin, L., Dehua, X., and Yanqin, L. (2016).

Evolution of Service Composition Based on Qos un-

der the Cloud Computing Environment. Proceedings

of ICOACS 2016, 2016:66–69.

Jatoth, C., Gangadharan, G., Fiore, U., and Computing,

R. B. (2018). SELCLOUD: a hybrid multi-criteria

decision-making model for selection of cloud ser-

vices. Soft Computing, pages 1–15.

Liu, H., Xu, D., and Miao, H. K. (2011). Ant colony op-

timization based service ﬂow scheduling with various

QoS requirements in cloud computing. Proceedings

- 1st ACIS International Symposium on Software and

Network Engineering, pages 53–58.

Liu, Z. Z., Chu, D. H., Song, C., Xue, X., and Lu, B. Y.

(2016). Social learning optimization (SLO) algorithm

paradigm and its application in QoS-aware cloud ser-

vice composition. Information Sciences, 326:315–

333.

Mezni, H. and Sellami, M. (2017). Multi-cloud service

composition using Formal Concept Analysis. Journal

of Systems and Software, 134:138–152.

Panda, S. K., Pande, S. K., and Das, S. (2018). Task Par-

titioning Scheduling Algorithms for Heterogeneous

Multi-Cloud Environment. Arabian Journal for Sci-

ence and Engineering, 43(2):913–933.

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

Research Opportunities, Scalable Computing : Prac-

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

Seghir, F. and Khababa, A. (2016). A hybrid approach us-

ing genetic and fruit ﬂy optimization algorithms for

QoS-aware cloud service composition. Journal of In-

telligent Manufacturing, pages 1–20.

Somu, N., Gauthama, G. R., Kirthivasan, K., and Shankar,

S. S. (2018). A trust centric optimal service ranking

approach for cloud service selection. Future Genera-

tion Computer Systems, 86:234–252.

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.

Tang, M., Dai, X., Liu, J., and Chen, J. (2017). Towards

a trust evaluation middleware for cloud service selec-

tion. Future Generation Computer Systems, 74:302–

312.

Thomas, M. V. and Chandrasekaran, K. (2017). Dynamic

partner selection in Cloud Federation for ensuring the

quality of service for cloud consumers. International

Journal of Modeling, Simulation, and Scientiﬁc Com-

puting, 08(03):1750036.

Zheng, H., Feng, Y., and Tan, J. (2016). A fuzzy QoS-

aware resource service selection considering design

preference in cloud manufacturing system. Interna-

tional Journal of Advanced Manufacturing Technol-

ogy, 84(1-4):371–379.

Zhou, J., Yao, X., Lin, Y., Chan, F. T., and Li, Y. (2018).

An adaptive multi-population differential artiﬁcial bee

colony algorithm for many-objective service compo-

sition in cloud manufacturing. Information Sciences,

456:50–82.

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science