ADAPTING CLOUD-BASED APPLICATIONS

THROUGH A COORDINATED AND OPTIMIZED RESOURCE

ALLOCATION APPROACH

Patrizia Scandurra

, Claudia Raibulet

, Pasqualina Potena

, Raffaela Mirandola

and Rafael Capilla

DIIMM, Universit`a degli Studi di Bergamo, BG, Dalmine, Italy

DISCo, Universit`a degli Studi di Milano-Bicocca, Milan, Italy

Politecnico di Milano, DEI, Milan, Italy

Depto. de Ciencias de la Computacion, Universidad Rey Juan Carlos, Madrid, Spain

Keywords:

Cloud Computing, Software Adaptation, Resource Allocation, Service-oriented Component Architecture.

Abstract:

Cloud computing is getting an enormous popularity for software companies as a way to save and optimize the

cost of large hardware and software infrastructure organizations demand. Also, the cooperation between cloud

layers constitutes a timely research challenge as allocation and optimization of (often virtualized) resources

is many times done in isolation or with poor interaction. In this paper we propose a framework that adapts

a cloud-based software application by providing an enhanced assembly of resources using the Pareto-optimal

solution to optimize the resource allocation with tight cooperation between the cloud layers.

1 INTRODUCTION

Cloud computing is an emerging computational

model where systems, both hardware and software,

are seamlessly deliveredand administered over the In-

ternet as services, giving the illusion to have them on

a local machine. This is achievable by exploiting web

technologies, virtualization techniques and large web

data centers. Depending on the Service Model (Mell

and Grance, 2011), a cloud can offer Infrastructure

(raw computing services such as CPU and storage) as

a Service (IaaS), Platform (COTS, tools, middleware

for developing and deploying applications) as a Ser-

vice (PaaS), and Software (end user applications) as a

Service (SaaS)

The SaaS layer generally exploits the Service-

Oriented Architecture (SOA) technology because, as

remarked in (Tsai et al., 2010), SOA and cloud com-

puting coexist, complement and support each other.

Obviously, the adoption of SOA requires taking into

account the typical features of cloud domain. In such

The lines dividing the layers are not distinctive. “Com-

ponents and features of one layer can also be considered to

be in another layer. For example, data storage service can

be considered to be either in as IaaS or PaaS.”(Tsai et al.,

2010).

a domain, for example, service providers publish the

services in deployable packages that can be easily

replicated and redeployed to different cloud hosting

environments. Hence, the increasing deployment of

cloud systems is leading to new research challenges

based on the cooperation and integration of a variety

of hardware and software resources and services that

are part of the cloud.

One of the aforementioned challenges we address

in this paper refers to the problem of optimizing re-

source allocation and adapting a cloud-based applica-

tion. Cloud-based applications require dynamic adap-

tation (Cheng et al., 2009) for several reasons, such

as: the introduction of new functionality, adaptations

in the runtime environment (e.g. workﬂow composi-

tion), or changes in the QoS level. Since the system

quality attributes are directly affected by the limita-

tion of hardware resources, the dynamic system adap-

tation

is strongly tied to the dynamic resource alloca-

tion. For example, the system reliability might change

dynamically according to various types of failures

(e.g., overﬂow failure, timeout failure, resource miss-

ing failure, network failure, or database failure), and

Throughout the paper, unless otherwise stated, the

term “system” and “cloud-based application” are used in-

terchangeable.

355

Scandurra P., Raibulet C., Potena P., Mirandola R. and Capilla R..

ADAPTING CLOUD-BASED APPLICATIONS THROUGH A COORDINATED AND OPTIMIZED RESOURCE ALLOCATION APPROACH.

DOI: 10.5220/0003919903550364

In Proceedings of the 2nd International Conference on Cloud Computing and Services Science (CLOSER-2012), pages 355-364

ISBN: 978-989-8565-05-1

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

the cloud infrastructure must react and adapt itself to

preserve the level of reliability.

In addition, the layers of a cloud architecture (i.e.,

IaaS, PaaS and SaaS) cooperate for the resource man-

agement through established contracts: each layer

usually provides resources to the upper layers by ex-

ploiting resources of the lower layers. Cloud lay-

ers attempt to perform optimal resource allocation

(e.g., the IaaS layer maximizes hardware resources

utilization) in order to satisfy user demands, but ex-

isting approaches usually optimize the decisions in

a single layer without considering dependencies and

constraints between layers. Hence, instead of view-

ing layers as separate control/optimization problems,

an explicit coordination between layers would allow

ﬁnding the appropriate trade-off between the, usu-

ally conﬂicting, objectives of the layers (Litoiu et al.,

2010).

In this work we address the interdependencies of

cloud layers. Our approach attempts to ﬁnd optimal

solutions for each layer when resource allocation is

needed and to support explicit cooperation between

layers. Different resource allocation actions may be

suitable for assuring a certain quality attribute (e.g.,

a different deployment of containers on VMs and/or

assignment of CPU and memory to the VMs could

still assure a certain reliability). Our solution allows

the veriﬁcation of the impact of the software adapta-

tion actions on the qualities attributes by predicting

the quality, obtained after the application of adapta-

tion actions for each change required, as a function

of the resource allocation. To this purpose, we adopt

a Pareto multi-objective optimization (Censor, 1977)

to optimize the resource allocation with tight cooper-

ation between the cloud layers.

The paper is organized as follows. Section 2 re-

ports some related work. Section 3 presents a small

application example adopted as running case study.

Section 4 describes the proposed coordination frame-

work. The details of its realization are given and ex-

empliﬁed through the case study in Section 5. Section

6 outlines some technical details about our experi-

mental cloud infrastructure. Finally, Section 7 con-

cludes the paper and outlines some future directions.

2 STATE OF THE ART

As stated in (Litoiu et al., 2010), notwithstanding the

increasing interest and diffusion of cloud computing

projects (see, e.g., EU’s FP7 RESERVOIR

and the

VOLARE (Papakos et al., 2010)projects), “there is no

http://www.reservoir-fp7.eu/

clear vision on how different layers of the cloud, pos-

sibly in different administrativedomains, can collabo-

rate to satisfy stakeholders goals”. To this purpose, in

(Litoiu et al., 2010) a conceptual optimization model

is proposed for satisfying the performance character-

istics both locally for each cloud layer (e.g., an SaaS

user requires an average application response time,

and the maximum hardware utilization is wished by

the IaaS providers) and globally, considering an inter-

layer cooperation. This paper has been inspired by the

work in (Litoiu et al., 2010) and proposes a tight in-

terlayer coordination schema for optimizing resource

allocation able to deal with the adaptation of cloud-

based applications.

Several research efforts have been devoted in the

last years to the deﬁnition of approaches and frame-

works for supporting optimization decisions for sin-

gle cloud layers. Most of them typically adapt a

cloud-based application by adopting different service

discovery and rebinding policies (see, e.g., (Papakos

et al., 2010)), varying application parametrization

and properties or modifying the application structure

(Baker et al., 2010), such as the ﬂow of the activi-

ties or processes. These adaptation approaches suffer

for the lack of models/techniques for analyzing the

quality attributes of a cloud system (Dai et al., 2009),

and are not driven by quality attribute trade-offs by

considering the particular features of the cloud com-

puting domain. Traditional web service composition

methods, for example, need to be enriched (Zou et al.,

2010) because service providers will likely publish

their web services at different cloud platforms, such

as Windows Azure Platform and Amazon S3. Fur-

thermore, existing algorithms for workﬂow schedul-

ing are not designed for multiple workﬂows with mul-

tiple QoS constrained scheduling and do not speciﬁ-

cally take into account the features of the cloud com-

puting (Xu et al., 2009).

The adaptation actions suggested by these ap-

proaches are not typically driven by the dynamic re-

source allocation with tight cooperation between the

layers. On the opposite, as claimed in (Yau and

An, 2009), the resource allocation approaches can-

not support dynamically modifying runtime environ-

ment changing for example, the workﬂow composi-

tion, QoS requirements, or workﬂow priorities and

resource status. Strategies have been developed, for

example, for maximizing the proﬁt of an application

provider under constraints on a maximum user re-

sponse time for each user class (or a minimum class

throughput) (Li et al., 2009), or optimizing the power-

performance tradeoff, and the adaptation beneﬁt and

cost of infrastructure providers (Jung et al., 2010).

With respect to the state of the art mentioned

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

356

above, our approach (to the best of our knowledge)

is the ﬁrst one that supports the adaptation of a cloud-

based application (including both the static and dy-

namic behavior) while resources are allocated with a

tight cooperation between the cloud layers. The adap-

tation actions may differ for adaptation cost and/or the

resulting system quality while changing the resource

allocation settings.

3 RUNNING CASE STUDY

This section presents a smartphone application used

throughout the paper to exemplify our approach. The

application, called Multimedia Service App, provides

an end-user multimedia (text and video information)

service to subscribed users. The news includes text

and topical videos available in MPEG2 format. Be-

sides, we assume that the smartphone user can re-

quire to the Multimedia Service App a geographical

map showing its locations (Alrifai and Risse, 2009).

Figure 1 shows the software architecture of the ap-

plication using the OSOA standard notation Service

Component Architecture (SCA) (SCA, 2007). It is

a thin client/server application: the server part is the

real application hosted on the cloud, while the client

(not shown in the ﬁgure) is assumed to be external and

connected via a wireless network to the Multimedia

Service App. The Multimedia Service App is a com-

posite application

that makes use of several services

for sending news to the client. The service (or service-

oriented component) ClientInterface processes infor-

mation on the client’s behalf. It interacts with the core

service MultimediaService, and also with the service

Compression to adapt the news content to the wireless

link. The service MultimediaService coordinates the

services: Transcoding to adapt the video content for

the smartphone format, Translation to adapt the text

for the smartphone format and draw the geographical

map, the service Merging to integrate the text with the

video stream for the limited smartphone display, and

Locations Database to collect information about the

localization of cells and thus provide a map showing

the user location.

In this work we will consider the following three

functionalities: (i) require news in textual format, (ii)

require news with both textual and video content (iii)

provide a geographical map with user location.

The SCA standard provides the composite concept as

a means to assemble heterogeneous service-oriented com-

ponents into logical groupings. An SCA composite usually

contains a set of components, services, references, the wires

(communication channels) that interconnect them.

Figure 1: SCA assembly of the Multimedia Service App.

4 A CLOUD COORDINATION

FRAMEWORK

This section presents a three-layered coordination ap-

proach (see Figure 2) based on three frameworks (one

for each cloud layer) – composing the Cloud Coor-

dination Framework – that dynamically perform re-

source allocation. Each framework provides a set of

manager components that handle the requests coming

from the other layers. Such components of a frame-

work interchange sensors data (related to measures of

the optimization) and actuators data (to drive the op-

timization) with the managers of the other layers thus

performing a continuous optimization activity.

The IaaS layer aims at maximizing the use of its

Hardware Resources (HRs). Such resources are vir-

tualized and offered as computing services (e.g., stor-

age, CPU and memory). The IaaS layer handles ser-

vice requests from the PaaS layer, such as Virtual

Machines (VMs) with particular performance charac-

teristics on memory, storage and processing capacity.

The PaaS layer, which offers platform services to the

SaaS layer, aims at optimizing the proﬁt by maximiz-

ing the number of applications it hosts and minimiz-

ing the resources it uses, and penalties it pays. The

ADAPTINGCLOUD-BASEDAPPLICATIONSTHROUGHACOORDINATEDANDOPTIMIZEDRESOURCE

ALLOCATIONAPPROACH

357

Figure 2: The Cloud Coordination Framework and its envi-

ronment.

PaaS layer uses resources of the IaaS layer by request-

ing VMs and storage and deploying application con-

tainers

on the VMs. Finally, the SaaS layer, provides

services to end users and maximizes the proﬁt, for ex-

ample setting the revenue proportional to the number

of users or to the throughput. It deploys the applica-

tions in PaaS containers considering topologies spe-

ciﬁc to each application.

In this section we describe how our coordination

framework allows the combination of the adaptation

– performed at the SaaS layer and driven by quality

attributes – of a cloud-based application and of re-

source allocation – performed at all layers. In fact, a

system quality (such as the perceived system reliabil-

ity for a user application) formalized as Service Level

Agreement (SLA) depends on the interaction between

certain layers, i.e., to a speciﬁc contract among the

stakeholders of the layers. If an adaptation request is

triggered in the SaaS layer, then the layer has to com-

bine the software adaptation actions and the resources

already owned or newly requested to the PaaS layer.

The PaaS layer, in turn, must ﬁnd an optimal decision

to satisfy the resources requested from the SaaS layer

through resources it already owns (deploying addi-

tional containers) or demand more to the IaaS layer.

In the last case, the IaaS, for example, must deploy

and allocate additional VMs in an optimal manner.

Considering quality analysis and implementation of

layers’ coordination, different strategies can be used

A container is a computing infrastructure for hosting

and running applications (one or more services).

depending on factors mainly related to the use of our

framework for evolution (at re-design time) or self-

adaptation (at run time) (Bucchiarone et al., 2010).

4.1 A Coordination Scenario

Figure 3 shows a concrete example of coordination

scenario as it would be performed by our coordina-

tion framework for the adaptation of a cloud-based

application. Below, we describe the main steps of

this process, which could be merely adopted in case

of evolution. In case of self-adaptation, we should

deﬁne simpler models and faster approaches must be

adopted for their solution in order to allow a prompt

run-time adaptation.

Step 1: SaaS Framework Deﬁnes Adaption Ac-

tions. The SaaS framework deﬁnes software adap-

tation actions for addressing the required changes

(claimed by a user or triggered by a monitor mod-

ule) by using the multi-objective optimization (Cen-

sor, 1977). A solution of such an optimization, called

Pareto solution or Pareto front, is the one that mini-

mizes a set of objectives (e.g., adaptation cost, proba-

bility of failure and response time) under quality con-

straints, such as on the required minimum level of re-

liability.

More formally: Let AS be the adaptation space

(i.e. the search space of our optimization process ob-

tained considering the set of all possible candidate so-

lutions) deﬁned as the Cartesian product of the option

sets of all application-speciﬁc adaptation actions, let

s be a candidate solution, let C ⊆ AS be a set of candi-

date solutions evaluated so far, and let q be a quality

criterion with a domain D

, and an order ≤

on D

so that s

≤

means that s

is better than or equal

to s

with respect to quality criterion q. Then, candi-

date solution s is Pareto-optimal with respect to a set

of evaluated candidate solutions C, iff:

∀s

′

∈ C ∃q : f

(s) ≤

′

)

If a candidate solution is not Pareto-optimal, then

it is Pareto-dominated by at least one other candidate

solution in C that is better or equal in all quality cri-

teria. Analogously, a candidate is globally Pareto-

optimal, if it is Pareto-optimal with respect to the set

of all possible candidates AS.

The solutions may differ in the adaptation actions

for adapting the applications or the resource alloca-

tion (e.g., the deployment of services on the contain-

ers, which have been previously assigned by the PaaS

layer). If the SaaS layer needs more resources (or

does not ﬁnd an admissible solution with the contain-

ers assigned by the PaaS layer), then the SaaS frame-

work proposes the Pareto solutions to the PaaS frame-

work. For each solution the resources necessary for

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

358

its application are indicated (e.g., a new deployment

topology) or ranges for container parameters (e.g.,

utilizations, throughput, response times of containers)

are reported. Obviously, the SaaS framework tries to

minimize, other than the cost for the software adap-

tation (e.g., the one for embedding a new service into

the system), the payment for resources to the PaaS

layer.

Step 2: PaaS Framework Tries to Satisfy the

SaaS Demands. Once the PaaS framework analyses

the Pareto solutions obtained from the SaaS frame-

work, it attempts to ﬁnd feasible resource allocations

or in case of failure, it suggests Pareto solutions to the

IaaS framework. Each solution suggests, for instance,

additional VMs, the allocation of VMs to containers.

Similarly to the SaaS framework, the PaaS framework

tries to minimize the payment for resources to IaaS

layer. Section 5 presents a couple of optimization

models that can be used in our framework at SaaS

and PaaS layers, and shows the beneﬁts of their in-

teraction.

Step 3: IaaS Framework Tries to Satisfy the

PaaS Demands. The IaaS framework analyzes the

Pareto set received from the PaaS framework. Sim-

ilarly to the SaaS and PaaS frameworks, the IaaS

framework ﬁnds a Pareto solution that minimize a

set of objectives (e.g., the resources that it does not

use and the penalties it pays) by trying to satisfy the

PaaS requests (e.g., by allocating VMs to processor

or changing VM settings, such as memory, CPU ra-

tio, etc.).

Step 4: Contract Re-negotiation between Layers.

If the layers’ frameworks do not ﬁnd a resource al-

location for addressing the required systems changes,

then layers’ contracts may be (re)-negotiated, e.g.,

the PaaS layer contracts additional resources with the

IaaS layer or the SLA is re-negotiated. For exam-

ple, in (Papakos et al., 2010), when the context of the

user device changes or the provided level of quality

attributes changes then the required quality levels are

re-negotiated. Note that this step will mostly depend

on runtime adaptation needs.

5 THE OPTIMIZATION MODEL

In this section we present a couple of optimization

models that we use in our framework at SaaS and

PaaS layers together with their application to the run-

ning case study.

Speciﬁcally, the proposed SaaS model supports

the adaptation of a cloud application by the service

selection and the resource allocation activities. In

particular, for each elementary service of an applica-

tion it indicates one of its available instances. The

model ﬁnds also the optimal amount of resources of

the containers to be allocated to their hosted services.

The model maximizes the Proﬁt of the SaaS provider

and the Throughput of the application (i.e., the aver-

age number of service responses per second) under a

given throughput constraint.

At the PaaS layer, the model aims to maximize

the Proﬁt of the PaaS provider and the Throughput of

the applications, which share a VM, under through-

put constraints (i.e., the throughput of the applications

served by the PaaS layer is assured within a certain

threshold).

5.1 The SaaS Problem Formulation

Let us now better formalize the model. Let us as-

sume a cloud-based application that offers a set F of

functionalities to users through the composition of n

elementary services. Let s

be the i-th service (1 ≤ i

≤ n). The afﬁliation of the services to the function-

alities is represented by the matrix SF(n× F), where

an element SF[i, f] is equal to 1 if the functionality f

includes the service s

, and 0 otherwise.

Let J

be the set of instances available for the i-

th service (i.e., the services provided by the SaaS

provider). We assume that the instances available for

the service s

are functionally compliant with it, i.e.,

each instance provides at least all services provided

by s

and requires at most all services required by s

Let K be the number of containers. The container

deployment is expressed by the matrix D(n, K), where

the entry D[i,k] is equal to 1 if s

is deployed on the

container k, and 0 otherwise. Each container provides

resources to the services, such as CPU time, memory

and bandwidth. As the average number of service-

requests per second arriving to a container one re-

source will become a bottleneck (this is also called

critical resource).

Model Variables. The x

(1 ≤ i ≤ n, j ∈ J

) vari-

ables are used for selecting an instance available for

the i-th service, namely x

is equal to 1 if the s

in-

stance is chosen, and 0 otherwise.

Furthermore, the variable T

(1 ≤ f ≤ F) repre-

sents the optimal throughput of the f-th functionality.

Function Objective. Maximizing the Proﬁt of the

SaaS provider and the Throughput of the cloud appli-

cation.

The Proﬁt of the SaaS provider can be expressed

as:

PROF =

∑

i=1

∑

j∈J

(1)

where c

is the price (in KiloEuros, KE) charged for

using the service s

ADAPTINGCLOUD-BASEDAPPLICATIONSTHROUGHACOORDINATEDANDOPTIMIZEDRESOURCE

ALLOCATIONAPPROACH

359

Figure 3: A coordination scenario for the adaptation of a cloud application.

The Throughput of an application can be formu-

lated as:

TH =

∑

f=1

(2)

where Pr

is the priority required (see (Yau and An,

2009) where the priorities for workﬂows are consid-

ered) for the functionality f.

Service Selection Constraint. For each service

, exactly one instance is chosen (i.e.,

∑

j∈J

∀i = 1. . . n).

Service-request Rates Requirement Constraint.

For each functionality f the constraint T

≤ SR

where SR

is service request rate of f, is added.

Throughput Requirement Constraint. For the

functionality f (if TR

≤ SR

, where TR

is the

throughput required by the users for f) the constraint

≥ TR

is added.

Available Critical Resource Constraint. For the

container k the following constraint is added:

∑

f=1

(

∑

i=1

D[i, k] · T

· SF[i, f] · bp

∑

j∈J

· x

) ≤

, where R

is the percentage of available critical re-

source of the container k. R

can be either a resource

assigned by the PaaS layer or the one required by the

SaaS Framework for ﬁnding feasible solutions. bp

is the number of invocations of s

within the function-

ality f, and λ

represents the service cost, namely

the percentage of critical resource required to serve a

service-request over the total available resource criti-

cal (see (Yau and An, 2009) for more details).

Resource Allocation. Therefore, the amount of

resource A

to be allocated to the service s

deployed

on the container k is:

∑

j∈J

· x

∑

f=1

· SF[h, f] (3)

Running Application Example: To solve the

model we have implemented the lexicographic

method (Marler and Arora, 2004) as follows. First we

have solved the optimization model maximizing the

SaaS proﬁt, then we have formulated the optimiza-

tion model that maximizes the throughput of the ap-

plication under the SaaS proﬁt constraint expressed

as a function of the real number ε. Finally, we have

found the set of Pareto optimal solutions by varying ε

(i.e., we have applied the ε-constraint approach (Mar-

ler and Arora, 2004)). For the experimentation we

have used the LINGO tool

, which is a non-linear

model solver, to produce the results.

We have parameterized the model with the values

of the available service instances as reported in the

Table 1. We have associated short names to the ser-

vices as illustrated in the ﬁrst column of the Table 1

(i.e., s

, s

,...,s

), and deployed the services (see the

last column) on three containers. The third column of

the Table lists, for each service, the set of alternatives.

For each alternative: the cost c

(in KiloEuros, KE)

is given in the fourth column, the percentage of criti-

cal resource required to serve a service-request λ

given in the ﬁfth column. Finally the number of in-

vocations bp

of s

within the functionalities 1, 2 and

3 are given in the sixth, seven and eight column, re-

spectively.

The critical resource of the containers is the CPU-

time. Let us consider the following values: the per-

centage of available resource of containers 1, 2 and 3

equal to 90%, 89%, 90% respectively; the priority re-

quired for the functionalities 1, 2 and 3 are 1, 2.5 and

3, respectively. The service request rates of function-

http://www.lindo.com/

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

360

Table 1: Parameters of the available instances.

Service Service Service Cost Perc. B. p. B. p. B. p. Cont. Dep.

ID name alter. c

of r. f. 1 f. 2 f. 3 D[i, k]

ClientInterface s

6 0.04 3 3 3 D[1, 2]

9 0.07

10 0.1

Multimedia s

4 0.03 5 7 6 D[2, 2]

Service s

12 0.2

14 0.3

Locations s

8 0.12 0 0 1 D[3, 1]

Database s

10 0.3

16 0.4

Transcoding s

3 0.04 0 1 0 D[4, 3]

10 0.08

14 0.2

Translation s

2 0.01 1 1 1 D[5, 1]

5 0.02

9 0.2

Merging s

5 0.01 0 1 0 D[6, 3]

14 0.03

19 0.2

Compression s

3 0.09 1 1 1 D[7, 1]

9 0.1

15 0.2

Figure 4: Pareto curve returned by the SaaS model.

alities 1, 2 and 3 are considered equal to 27, 30 and 37

req/sec, respectively. Finally, the minimum through-

put of functionalities 1, 2 and 3 are set to 7, 12 and 12

req/sec, respectively.

Figure 4 reports the approximate Pareto curve ob-

tained from solving the model. Each Pareto solution

represents a conﬁguration of services and an alloca-

tion of resources that maximize both the SaaS proﬁt

(in KiloEuros, KE) and the throughput of the applica-

tion (in request/second, req/sec).

Table 2 details the results. Each row of the table

represents the choice of services and the functional-

ity throughput (i.e., a Pareto solution) that the model

suggests. The choice is represented as two vectors.

Each element of the ﬁrst vector is the name of the

service instance available, whereas each element of

the second one is the functionality’s throughput. Be-

side these vectors, the throughput objective, the SaaS

proﬁt, and the value of the ε parameter are also re-

ported.

For example, model results claim that if through-

put objective is equal to 213 req/sec (represented on

the x-axis), then the maximum proﬁt of the SaaS is

87 KE. Such solution point is: [s

, s

] [T

= 27 req/sec, T

= 30 req/sec, T

= 37

req/sec], where all the replacements services are spec-

iﬁed, as well as the optimal throughput of each func-

tionality. The model results also show that the optimal

solution cost increases (up to 97 KE) while decreasing

the throughput objective (down to 105 req/sec).

5.2 The PaaS Problem Formulation

Let R be the resources (assigned by the IaaS layer)

provided by a VM to its m hosted applications, such

as CPU time, memory and bandwidth.

ADAPTINGCLOUD-BASEDAPPLICATIONSTHROUGHACOORDINATEDANDOPTIMIZEDRESOURCE

ALLOCATIONAPPROACH

361

Table 2: Results of the SaaS model.

Pareto Solution

, s

]

= 7 req/sec, T

= 12 req/sec, T

= 22.666 req/sec]

Throu. Obj.= 105 req/sec Cost Obj.= 97 KE

, s

]

= 7 req/sec, T

= 12 req/sec, T

= 24.532 req/sec] ε = 1

Throu. Obj.= 110.597 req/sec Cost Obj.= 96 KE

, s

]

= 7 req/sec, T

= 14.352 req/sec, T

= 37 req/sec] ε = 2

Throu. Obj.= 153.882 req/sec Cost Obj.= 95 KE

, s

]

= 7 req/sec, T

= 17.614 req/sec, T

= 37 req/sec] ε = 3

Throu. Obj.= 162.037 req/sec Cost Obj.= 94 KE

, s

]

= 7 req/sec, T

= 21.263 req/sec, T

= 37 req/sec] ε = 7

Throu. Obj.= 171.157 req/sec Cost Obj.= 91 KE

, s

]

= 27 req/sec, T

= 30 req/sec, T

= 37 req/sec] ε = 10

Throu. Obj.= 213 req/sec Cost Obj.= 87 KE

Model Variables. The variable

(1 ≤ i ≤ m) repre-

sents the optimal throughput of the i-th application.

Function Objective. Maximizing the Proﬁt of the

PaaS provider and the Throughput of the m applica-

tions.

The Proﬁt can be expressed as:

PROF =

∑

r=1

∑

i=1

¯c

(4)

where ¯c

represents the price (in KE) charged for

using one percent of the resource r, and

is the

amount of r assigned to the application i (

Similarly to the SaaS model, the Throughput ob-

jective can be formulated as:

TH =

∑

i=1

(5)

where

is the priority required for the application i.

Service-request Rates Requirement Constraint.

For the application i the constraint

≤

, where

is service request rate of i, is added.

Throughput Requirement Constraint. For the ap-

plication i (if

≤

, where

is the throughput

required by the users for i) the constraint

≥

added.

Available Critical Resource Constraint. For

the resource r the following constraint is added:

can be expressed as

∑

f=1

· pexec

, where pexec

is the probability that the f-th application functionality will

be invoked. It must hold: pexec

>= 0 and

∑

f=1

pexec

∑

i=1

≤ av

where av

is the percentage of avail-

able resource r of the VM, and

, similarly to the

service cost, is the percentage of resource r required

to serve a service-request of the application i over the

total available resource critical.

Resource Allocation. Therefore, the amount of

resource r to be allocated to the application i is:

(6)

5.3 Cooperation between SaaS and

PaaS Optimization Models

In this section we outline two examples where the

SaaS and the PaaS model cooperate together. We

show how this latter model allows adapting the

smartphone application, as proposed by the Pareto

solutions in Figure 4, by using the PaaS resource

allocation activity (see Step 2 in Section 4).

Running Application Example: The container 1

of the smartphone application (here also called app 1)

belongs to a VM, which is also shared by other two

cloud applications (here also called app 2 and app 3,

respectively).

Let us consider the following values: the price

charged for using one percent of VM’s CPU equal to

2 KE; the VM has the 100% of CPU; the priority re-

quired for the app1, app 2 and app 3 are set to 2, 1.5

and 1, respectively. The probabilities that the func-

tionalities 1, 2 and 3 of app1 are considered equal

to 0.3, 0.3 and 0.4, respectively. Thus the average

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

362

service request rate

and throughput requirement

of app 1 are equal to 31.9 and 10.5 req/sec, re-

spectively.

Example 1: PaaS Framework assures the re-

quests of the smarthphone provider and the maximum

throughput for app 2 and app 3.

Let us consider the following values for app 2 and

app 3, respectively: the percentages of CPU usage at a

very low average load are 0.6% and 0.8%; the service

request rates are 20 and 24 req/sec; the throughput

requirements are 8 and 9 req/sec.

The PaaS model for the SaaS Pareto point

(153.882 req/sec, 95 KE) – for which the average op-

timal throughput

of app 1 is equal to 21.205 req/sec

– ﬁnds the following feasible solution: [

= 21.205

req/sec,

= 20 req/sec,

= 24 req/sec]. The PaaS

proﬁt is equal to 138.68 KE, while the throughput ob-

jective is equal to 96.411 req/sec.

Example 2: PaaS Framework satisﬁes the smarth-

phone provider, but not the maximum throughput for

app 2 and app 3.

Starting from the initial values of the model pa-

rameters of Example 1, let us increase to: 2% the per-

centage of CPU required by app 2 and app 3; 24 and

34 req/sec the service requests rates of app 2 and app

3, respectively.

The PaaS model for the SaaS Pareto point (213

req/sec, 87 KE) – for which

is equal to 31.9 req/sec

– ﬁnds the following feasible solution: [

= 31.9

req/sec,

= 14.8 req/sec,

= 9 req/sec]. The PaaS

proﬁt is equal to 200 KE, while the throughput objec-

tive is equal to 95 req/sec.

These examples highlight the beneﬁts of the coor-

dination between the SaaS and the PaaS layers. They

showhowthe SaaS provider is able to adapt the smart-

phone application by using the resource allocation ac-

tivity of the PaaS layer.

6 EXPERIMENTAL

ENVIRONMENT

Today, many cloud applications in the SaaS layer

are implemented using service-oriented assemblies

such as the SCA (SCA, 2007) approach. SCA is an

XML-based metadata component model that copes

with heterogeneity by allowing various implementa-

tion technology (as Java, C++, Spring, PHP, BPEL,

Web services, etc.), middleware programming APIs,

and communication protocols.

We have been conducting our experiments on

a private cloud environment based on the software

framework Eucalyptus (Nurmi et al., 2009). Euca-

lyptus is an open source cloud computing software

framework that implements the IaaS model by allow-

ing users to run and control entire virtual machines on

cloud infrastructure. On the top of such virtual ma-

chines, as application containers we install: the Java

platform enterprise edition (Java EE), Apache Tom-

cat, various web services containers, and (more im-

portantly) the SCA runtime platform Apache Tuscany

(Tuscany, 2010).

The platform Tuscany supports different tech-

nology/protocols (e.g., WSDL binding to con-

sume/expose web services, JMS binding to re-

ceive/send Java Message Service, etc.) and recently,

with the incubation project Nuvem, addresses some

cloud-speciﬁc issues. Using this platform, applica-

tions (possibly containing components implemented

in different languages) can be integrated by repre-

senting them in terms of SCA assemblies deployed

and spanned across multiple SCA domains. An SCA

domain typically represents a set of services provid-

ing an area of business functionality that is controlled

by a single organization. As an example, for the ac-

counts department in a business, the SCA domain

might cover all ﬁnancial related function, and it might

contain a series of composites dealing with speciﬁc

areas of accounting, with one for customer accounts,

another dealing with accounts payable (SCAspec,

2007). We use Tuscany as the primary infrastructure

solution for creating and hosting the domains, com-

ponents, etc. These domains are then spread across

the cloud and enterprise infrastructure, thus creating

a composite service-oriented application.

Finally, our optimization framework uses (as we

already mentioned previously) Lingo to solve the op-

timization models at all three layers. Up to now, we

havebeen focused on the coordination of the SaaS and

PaaS layers, upon each we build a coordination man-

ager component to deal with handling requests. Sim-

ilarly to the Eucalyptus framework that implements

high-level system components in terms of Web ser-

vices, we have chosen to implement each manager

component as a stand-alone Web service exposing

well-deﬁned language-agnostic API in the form of a

WSDL document. In this paper, we focused on the

description of the overall workﬂow of the compound

managers behaviors. Providing details about the ﬁne-

grained architecture of such managers is out of the

scope of this paper.

7 CONCLUSIONS AND FUTURE

WORK

We have argued the need that cooperation between

the cloud layers should be improved in order to sat-

ADAPTINGCLOUD-BASEDAPPLICATIONSTHROUGHACOORDINATEDANDOPTIMIZEDRESOURCE

ALLOCATIONAPPROACH

363

isfy the resource allocation in an optimal way thus

avoiding collapsing the cloud. Such layered coordina-

tion schema, as shown in this paper on a smartphone

application, beneﬁts the adaptation of a cloud-based

application. To this extent, a couple of optimization

models – designed for the SaaS and PaaS layers – are

presented, and their application/coordination is also

illustrated through the case study.

Currently, we are implementing a prototype of

our coordination framework to handle multiple dis-

tributed applications and large scale infrastructures

by following both a centralized and a decentralized

paradigm. We intend to apply our approach on real-

istic examples to validate it, study its scalability, and

compare it with existing approaches. We believe that

our approach may provide a valid solution to over-

come some of their drawbacks. For example, using

our approach it would be possible to consider the par-

ticular features of the cloud domain (e.g., services

can be deployed in different clouds) by expressing the

quality attributes of an application as a function of the

dynamic resource allocation.

REFERENCES

Alrifai, M. and Risse, T. (2009). Combining global opti-

mization with local selection for efﬁcient QoS-aware

service composition. In WWW, pages 881–890.

Baker, T., Taleb-Bendiab, A., Randles, M., and Karam, Y.

(2010). Support for adaptive cloud-based applications

via intention modelling. In Proc. of 3rd International

Symposium on Web Services.

Bucchiarone, A., Cappiello, C., Nitto, E. D., Kazhamiakin,

R., Mazza, V., and Pistore, M. (2010). Design for

adaptation of service-based applications: Main issues

and requirements. In ICSOC/ServiceWave 2009 Work-

shops, LNCS, pages 467–476.

Censor, Y. (1977). Pareto Optimality in Multiobjective

Problems. Appl. Math. Optimiz., 4:41–59.

Cheng, B. H. C. et al. (2009). Software engineering for self-

adaptive systems: A research roadmap. In Software

Engineering for Self-Adaptive Systems, pages 1–26.

Dai, Y.-S., Yang, B., Dongarra, J., and Zhang, G. (2009).

Cloud service reliability: Modeling and analysis.

Proc. of 15th Paciﬁc Rim Inter. Symp. on Depend.

Comp.

Jung, G., Hiltunen, M. A., Joshi, K. R., Schlichting, R. D.,

and Pu, C. (2010). Mistral: Dynamically managing

power, performance, and adaptation cost in cloud in-

frastructures. Distributed Computing Systems, Inter-

national Conference on, 0:62–73.

Li, J., Chinneck, J., Woodside, M., Litoiu, M., and Iszlai, G.

(2009). Performance model driven qos guarantees and

optimization in clouds. In Proc. of the ICSE Workshop

on Software Engineering Challenges of Cloud Com-

puting, CLOUD ’09, pages 15–22.

Litoiu, M., Woodside, M., Wong, J., Ng, J., and Iszlai, G.

(2010). A business driven cloud optimization architec-

ture. In Proceedings of the 2010 ACM Symposium on

Applied Computing, SAC ’10, pages 380–385. ACM.

Marler, R. and Arora, J. (2004). Survey of multi-objective

optimization methods for engineering. Structural and

Multidisciplinary Optimization, 26:369–395.

Mell, P. and Grance, T. (September 2011).

The NIST deﬁnition of cloud computing.

http://csrc.nist.gov/publications/nistpubs/800-

145/SP800-145.pdf.

Nurmi, D., Wolski, R., Grzegorczyk, C., Obertelli, G., So-

man, S., Youseff, L., and Zagorodnov, D. (2009). The

eucalyptus open-source cloud-computing system. In

Cappello, F., Wang, C.-L., and Buyya, R., editors, CC-

GRID, pages 124–131. IEEE Computer Society.

Papakos, P., Capra, L., and Rosenblum, D. S. (2010).

Volare: context-aware adaptive cloud service discov-

ery for mobile systems. In Proceedings of the 9th In-

ternational Workshop on Adaptive and Reﬂective Mid-

dleware, ARM ’10, pages 32–38.

SCA (2007). OSOA. Service Component Architecture

(SCA) www.osoa.org.

SCAspec (2007). SCA Assembly Model Speciﬁcation, Ver-

sion 1.00, March 15 2007.

Tsai, W.-T., Sun, X., and Balasooriya, J. (2010). Service-

oriented cloud computing architecture. Information

Technology: New Generations, Third International

Conference on, pages 684–689.

Tuscany (2010). Apache Tuscany.

http://tuscany.

apache.org/

Xu, M., Cui, L., Wang, H., and Bi, Y. (2009). A multiple qos

constrained scheduling strategy of multiple workﬂows

for cloud computing. Parallel and Distributed Pro-

cessing with Applications, International Symposium

on, 0:629–634.

Yau, S. and An, H. (2009). Adaptive resource allocation for

service-based systems. In Internetware ’09: Proceed-

ings of the First Asia-Paciﬁc Symposium on Internet-

ware.

Zou, G., Chen, Y., Yang, Y., Huang, R., and Xu, Y. (2010).

Ai planning and combinatorial optimization for web

service composition in cloud computing. In Proc. In-

ternational Conference on Cloud Computing and Vir-

tualization (CCV-10).

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

364