Towards a Goal-oriented Approach to Adaptable Re-deployment of

Cloud-based Applications

Patrizia Scandurra

, Marina Mongiello

, Simona Colucci

and Luigi Alfredo Grieco

Dip. di Ingegneria Gestionale dell’Informazione e della Produzione, Universit

a di Bergamo, Dalmine (BG), Italy

Dipartimento di Ingegneria Elettrica e dell’Informazione, Politecnico di Bari, Bari, Italy

Keywords:

Cloud Applications, Adaptation, Deployment, Goal-model.

Abstract:

Due to the on-demand and dynamic nature of Cloud, there is an increasing interest for automated management

of adaptation and (possibly) re-deployment of cloud applications to realize quality requirements and evolution

needs autonomously at run-time. This paper proposes a fast and automated approach for adapting and re-

deploying a cloud application at run-time as dictated by evolution needs and sudden changes in the operating

environment conditions. The proposed approach exploits a graph-based model and an algorithm that extracts

a sub-graph identifying the adaptation processes to be executed according to evolution changes. The approach

is general enough to be implemented by any cloud application management framework. A TOSCA-based

description of the structure and management aspects of the cloud application may be updated according to

the above mentioned sub-graph. Then, this description may be processed by a TOSCA-compliant runtime

environment to effectively adapt and possibly re-deploy the cloud application in an automated manner. The

paper also illustrates the instantiation of this generic approach for adapting an e-commerce cloud application.

1 INTRODUCTION

Modern service-oriented software applications, like

those envisioned in cloud computing scenarios, op-

erate in highly dynamic and often uncertain and un-

predictable environments that can degrade their qual-

ity of service (such as availability, reliability, per-

formance, etc.). Moreover, rapid elasticity and self-

service – to enable on demand dynamic growing and

shrinking of resources and service composition de-

pending on the user/evolution needs (e.g., extending

the storage of an email account, adding temporarily a

social login service to the conventional authentication

system, etc.) – are becoming key goals in cloud ser-

vice and application management (Lehrig et al., 2015;

Dubois et al., 2015; Andrikopoulos et al., 2013).

Managing the adaptation of complex applications

over clouds with high evolving resource provisioning

and service compositions, while guaranteeing qual-

ity attributes, is one of the emerging problems in

the cloud era, especially for data-intensive applica-

tions (Casale et al., 2015). In particular, automa-

tion of cloud application deployment and manage-

ment (including adaptation) across clouds, regardless

of provider platform or infrastructure, is becoming a

prerequisite to realize key cloud properties (see, for

example, the works (Wettinger et al., 2015; Brogi

et al., 2015; Andrikopoulos et al., 2013), to name a

few, addressing such topics).

In this paper, we investigate the challenge in

adapting and re-deploying cloud applications at run-

time according to evolution needs and operating en-

vironment conditions changes (such as brokerage of

new resources, QoS optimization and tradeoffs, fail-

ures, changes in the workload and size of jobs, elastic-

ity requirements based on application-level metrics,

etc.). Cloud adaptation essentially requires conﬁgu-

ration and elasticity changes in the application topol-

ogy at any cloud layer through low-level actions at

IaaS (Infrastructure as a Service) level, such as a new

Virtual Machine (VM) is added or a resource-related

parameter of a VM is changed (e.g., a new disk is at-

tached), or high-level actions at the PaaS (Platform

as a Service)-SaaS (Software as a Service) levels,

such as moving an application service from one IaaS

provider to another or adding a new service.

To this purpose, we propose an automated ap-

proach for adapting and re-deploying a cloud appli-

cation at run-time as dictated by evolution needs and

sudden changes in the operating environment condi-

tions. The proposed approach exploits a goal-oriented

graph-based model and a fast algorithm (based on

Scandurra, P., Mongiello, M., Colucci, S. and Grieco, L.

Towards a Goal-oriented Approach to Adaptable Re-deployment of Cloud-based Applications.

In Proceedings of the 6th International Conference on Cloud Computing and Services Science (CLOSER 2016) - Volume 1, pages 253-260

ISBN: 978-989-758-182-3

253

the well-known Dijkstra algorithm) that extracts a

sub-graph identifying the adaptation processes to be

executed according to evolution changes/events. A

TOSCA-based

description of the structure and man-

agement aspects of the cloud application may be up-

dated according to the above mentioned sub-graph.

The description may be then processed by a TOSCA-

compliant runtime environment to effectively adapt

and possibly re-deploy the cloud application in an au-

tomated manner. The paper also illustrates the instan-

tiation of the approach for a scalability adaptation sce-

nario in an e-commerce cloud application.

The proposed approach is general enough to be

implemented by any cloud application management

framework. The proposed approach can be used, for

example, to strengthen current management engines

(e.g., current auto-scaling tool available in the cloud

market) or to support adaptation decision making at

run-time in more complex management frameworks

(see, for example, the initiative (Brogi et al., 2015)).

This paper is organized as follows. Section 2

provides some background assumptions and concepts

about TOSCA for realizing the proposed approach.

Section 3 introduces a running example used through-

out the paper. Section 4 presents our goal-oriented

adaptation approach and exempliﬁes it on the run-

ning example; in particular, it presents a scalability

scenario of the application example involving scaling

and adding of an additional login service as adapta-

tion actions. Section 5 reports some related initia-

tives, while Section 6 provides concluding remarks

and challenges we want to address as future work.

2 BACKGROUND ASSUMPTIONS

We assume that a cloud application is described in

terms of the OASIS standard TOSCA. TOSCA al-

lows to express in a portable manner how to auto-

matically deploy and manage complex cloud appli-

cations (Binz et al., 2014) by requiring developers

to deﬁne an abstract topology of a multi-component

Cloud application and to create plans describing its

deployment and management. The proposed ap-

proach can be therefore implemented in any TOSCA-

compliant cloud platform offering a TOSCA con-

tainer (like OpenTOSCA) able to process an archive

format called CSAR (Cloud Serivce ARchive) pack-

aging the TOSCA Cloud application speciﬁcation to-

gether with concrete implementation and deployment

The OASIS Topology and Orchestration lan-

guage (http://docs.oasis-open.org/tosca/TOSCA/v1.0/os/

TOSCA-v1.0-os.html)

artifacts. TOSCA containers not only support appli-

cation at deployment time, but also at run-time.

In TOSCA, the architecture (or topology) of a

cloud application is explicitly modeled by a graph

where nodes represent the components of the appli-

cation and edges represent different kinds of relations

between these components. Relations may be, for ex-

ample, one component is “hosted on”, “depends on”,

or “communicates with” another component. Nodes

and edges in the topology may deﬁne additional prop-

erties, the management operations they offer (e.g.,

how to setup the component, establish a relation, de-

ploy artifacts, scale-up, or backup), the artifacts re-

quired to run the component, or non-functional re-

quirements. Figure 2 in Section 3 shows the topol-

ogy delivering the e-commerce cloud application we

consider as running example throughout the paper.

Without loss of generality, we assume that each

server component is installed in a stand-alone VM.

Accordingly, the scaling up/down the cloud applica-

tion taken as example in this work typically involves

adding/removing extra software servers, and hence

extra VMs in a cloud environment.

Moreover, we assume that a TOSCA container

adopts a declarative processing mechanism (Brogi

et al., 2014), i.e. it deploys the application by trying

to automatically excerpt a deployment plan from the

application topology. Essentially, the CSAR engine

(a) ﬁrst deploys the nodes without requirements on

other nodes, and then (b) until all nodes have been de-

ployed, it searches the nodes whose requirements are

satisﬁed (by the capabilities of the already deployed

nodes) and deploys them. This way of processing

allows us to easily adapt the current application de-

ployment by adapting directly the TOSCA applica-

tion topology. Alternatively, an imperative processing

model could be adopted by taking the CSAR archive

and deploying the application according to a TOSCA

build plan (deﬁned using a workﬂow modeling lan-

guage such as BPMN

or WS-BPEL

) combining the

operations offered by the nodes in the topology.

3 RUNNING EXAMPLE

In this paper, we consider a scalability scenario where

an e-commerce cloud application is adapted to pro-

vide the amount of load balancing capacity required

to distribute application trafﬁc. The e-commerce

cloud application is divided into multiple tiers (see

http://www.bpmn.org/

http://docs.oasis-open.org/wsbpel/2.0/OS/

wsbpel-v2.0-OS.html

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

254

Figure 1: Basic, multi-tier e-commerce web application.

the logical structure of such application shown in Fig-

ure 1 in a free-style notation). An elastic load bal-

ancer is used as frontend for accepting and distribut-

ing end users’ requests automatically across multi-

ple application server instances (the back end) in the

cloud. Moreover, it has the power to cache con-

tent according to some rules to set; this means that

when a request comes for some content that exists

in the cache, the load balancer can simply deliver it

directly to the browser, rather than handing the re-

quest to the application server(s). The real applica-

tion tiers (presentation, business and data tiers) are

implemented through an Apache web server for han-

dling http requests, a middle-tier Tomcat application

server for implementing the business logic, and a

backend MySQL database with data store and pro-

cessing. These servers work together to handle end

users’ requests. The corresponding topology descrip-

tion in TOSCA is shown in Figure 2. The Presenta-

tion Tier and Business Tier are declared scalable (by

the multiplicity 1..n), and the composite application’s

template includes a Load Balancer node with content

caching that understands how to connect to and scale

them. The DBTier is also scalable. The Presenta-

tion Tier includes the entire set of dependent service

components necessary for deploying the e-commerce

web application on an Apache web server (with PHP

Module support, for example). It’s required hosting

environment also includes a Linux Operating System

(OS), a VM container and a “Tier container”

to log-

ically group all related components. Similarly for the

other tiers.

Initially, the application is deployed (see Figure 1)

on ﬁve server instances in the Cloud to support a small

number of customers. Depending on the application

workload, the servers at each tier can be stressed at

different times and the implementation ideally needs

to scale up or down the resources at the appropri-

ate tier so as to maintain the overall quality require-

ments of the application while minimizing the cost

of resources used. To this purpose, each tier is elas-

tically scaled independently to adapt the application

in response to load changing demand. In particular,

a separate elastic scaling is adopted for the Presenta-

“Tier” is a topological concept used to describe sets of

nodes (or sub-topologies) that can be deployed and man-

aged as a single group.

tion tier and the Business tier because the process-

ing components are more computation intensive or

used less frequently than the User Interface compo-

nents. For example, additional server instances can be

launched automatically (e.g., in the example of Fig-

ure 3 one Apache server and two Tomcat servers are

added) when the load on the current instances rises,

for example, to 70 percent, and then some server in-

stances can be removed to reduce the cost of service

provision when the load falls to 40 percent.

Adaptation Requirements. As types of adaptation,

various reactive or anticipatory scaling actions could

be done vertically (i.e., scale up/down) or horizon-

tally (i.e., scale out/in) to handle the increased de-

mand. The load balancer with caching, the mes-

sage queues, the presentation tier and the business-

tier can be scaled horizontally by adding more cache

and queue devices and server instances at each tier

into the computing cloud platform. The database

tier can be scaled both vertically, by adding more

resources to the same computing pool (e.g., more

disks), and horizontally, by using a MySQL master-

slaves conﬁguration model with data replication. In

the last case, a MySQL Master is initially deployed

and, when the database tier is scaled up, extra MySQL

Slaves are added and conﬁgured with replication from

the MySQL Master. The numbers of load balancer

servers and MySQL Master database do not change.

These scaling actions have different prices and real-

ization costs that may also change at run-time. Usu-

ally, vertical scaling can handle most sudden, tem-

porary peaks in application demand on cloud infras-

tructures since they are not typically CPU intensive

tasks. Sustained increases in demand, however, re-

quire horizontal scaling and load balancing to restore

and maintain peak performance. Horizontal scaling is

also manually intensive and time consuming, requir-

ing a technician to add machinery to the customers

cloud conﬁguration, and this may be not productive

since trafﬁc may settle to its pre-peak levels before

new provisioning can come on line.

In addition to scaling actions, that mostly affect

the PaaS and IaaS layers, the e-commerce cloud appli-

cation can be adapted by adding a new service com-

ponent at SaaS level to reﬂect an evolution need in

the application requirements. Essentially, to increase

sales for a certain event calendar (e.g., in the Christ-

mas period or Black Fridays), a new social login com-

ponent (for example, Facebook) is added temporarily

to the application to allow not registered users to pur-

chase orders by using their personal social account

credentials (e.g., their Fb authentication credentials)

to authenticate into the system.

Towards a Goal-oriented Approach to Adaptable Re-deployment of Cloud-based Applications

255

Figure 2: TOSCA topology of the e-commerce web application.

Figure 3: Scaled, multi–tier e-commerce web application.

4 ADAPTATION APPROACH

The proposed methodology for the generation and the

execution of adaptation plans is summarized in the

steps shown in Figure 4. The proposed approach

helps in deciding and guiding the necessary adapta-

tion changes to carry out at different Cloud tiers of

the application as dictated by evolution needs. Es-

sentially, the management framework implementing

the proposed approach observes, according to con-

ﬁgured monitoring parameters (i.e., sampling rate),

and generates real-time graphs by aggregating met-

rics originated from multiple sources

. From these

graphs, appropriate adaptation processes are deter-

mined and translated on-the-ﬂy into TOSCA-based

adaptation plans.

Metrics and monitor mechanisms/frameworks for

Metrics can be obtained either from native Cloud mon-

itoring systems or from custom metric collectors (probes)

provided by the user during deployment.

Figure 4: Generation and execution of an adaptation plan.

identifying the evolution events or predict future

changes that may trigger the Cloud application adap-

tation at run-time and eventually its re-deployment are

out of the scope of this paper.

4.1 Adaptation Model

The proposed adaptation approach is grounded on a

graph-based model. This model generalizes the ele-

ments involved in the composition of adaptation pro-

cesses in heterogeneous scenarios of interest.

In particular, different scenarios are described in

terms of three inter-related building entities: evolu-

tion events, adaptation processes triggered by events

and cloud node tiers implementing adaptation pro-

cesses. Formally, the general model is deﬁned as an

Adaptation Graph in the following:

Deﬁnition 1 (Adaptation Graph (AG)). Let EV, AP,

CT be three sets describing events, adaptation pro-

cesses and cloud tiers, respectively.

An Adaptation Graph is a weighted directed graph

G = {V, E}, such that:

• V = EV ∪ AP ∪ CT, i.e., a vertex can model an

event, an adaptation process or a cloud node tier;

• E = (EV × AP) ∪ (AP × CT) ∪ (CT × EV), i.e.,

an edge connects either an event to an adaptation

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

256

process or an adaptation process to a cloud tier

or a cloud tier to an event;

• a function c : E → ℜ

∪ {0} labels edges in E as

follows:

1. c(v, w) is the cost of performing an adaptation

process w triggered by an event v, for v ∈ EV

and w ∈ AP

2. c(v, w) is the cost of implementing an adapta-

tion process v in a cloud tier w, for v ∈ AP and

w ∈ CT

3. c(v, w) = 0, for v ∈ CT and w ∈ EV

The model is aimed at ﬁnding the best composi-

tion of adaptation processes satisfying a goal, gener-

ated at run-time by an occurring event. In the Adap-

tation Graph, the adaptation cost can be computed

based on the performance of the physical platform

and/or deﬁned by the system administrator depending

on the user’s proﬁles of the application.

In the following, a Goal is deﬁned according to

the proposed model.

Deﬁnition 2 (Goal). Given an AG R = (V, E), deﬁned

according to Deﬁnition 1, a Goal G in R is an ordered

pair (s, d) with s ∈ EV ∩V and d ∈ EV ∩V .

Intuitively, a goal is deﬁned as a transition from

an original status (modeled by the event node s) to a

destination status (modeled by the event node d).

The reader may note that, given the graph struc-

ture of an AG R, if a goal (s, d) is identiﬁed in

R, all paths connecting s to d need to match pat-

terns made up by sequences of ordered quadruples

(Event, AdaptationProcess, CloudTier, Event). Of

course, many of such paths exist. This paper only fo-

cuses on minimum cost paths and on possible Goal-

oriented Adaptation Subgraphs (GASs) of R, de-

ﬁned by such paths.

Deﬁnition 3 (Goal-oriented Adaptation Subgraph

(GAS)). Given an AG R = (V, E), deﬁned according

to Deﬁnition 1, and a goal (s, d) in R, deﬁned accord-

ing to Deﬁnition 2, a Goal-oriented Adaptation Sub-

graph (GAS) of R is a direct graph S = (V

, E

), such

that:

• S ⊆ R;

• s ∈ V

and d ∈ V

;

• E

includes a path p connecting s to d, such that

cost(p) ≤ cost(r) for every path r in R connecting

s to d.

Algorithm Adapt is now proposed for ﬁnding a

GAS S of an AG R = (V, E), given R and a goal

(s, d) in R. In Row 2, the Dijkstra algorithm (Dijkstra,

1959), well-known form graph theory, is called. The

algorithms associates to each node v

∈ V , the cost of

the (minimum) path from s to v

and the node v

i−1

Data: An AG R = (V, E), a goal (s, d) in R,

Result: A GAS S = (V

, E

) of R

1 let c be the function labeling R;

2 solve DIJKST RA(R, c, s)

3 read a minimum cost path p

min

from s to d

4 add all nodes in p

min

to V

5 add all edges in p

min

to E

Algorithm 1: Adapt.

preceding v

in the minimum cost path. Then (Row 3),

the minimum cost path from s to d is read from the re-

sults of Dijkstra algorithm and S is consequently built

in Rows 4–5. Note that Algorithm Adapt is based on

the Dijkstra algorithm (Dijkstra, 1959), and thus, its

time complexity depends on the chosen implementa-

tion. In particular, if Fibonacci Heap is adopted as pri-

ority queue, the algorithm requires O(|E|+|V |log|V |)

running time in the worst case.

At instantiation level, the model presented hereby

needs to be referred to an application scenario, for

which speciﬁc events, adaptation processes and cloud

tiers have to be identiﬁed, together with the relations

among them. This activity leads to the deﬁnition of

an application-speciﬁc AG. Then, when an occurring

event requires intervention, the following steps have

to followed: i) a contextual AG is built by customiz-

ing the application-speciﬁc AG on the basis of run-

time settings; ii) a Goal is identiﬁed, again depending

on run-time settings; iii) the GAS determined by the

AG and the Goal is computed.

4.2 Model Instantiation

In this section we instantiate the graph model pre-

viously deﬁned by considering a concrete adapta-

tion scenario w.r.t. scalability of the e-commerce

cloud application taken as running example. Let

us suppose the e-commerce service is initially de-

ployed with a Load Balancer with one cache, one

Apache web server instance, two Tomcat servers, one

MySQL Master server instance. In order to illustrate

the composition of adaptation processes required by

our example, we need to refer to the AG model in-

stance in Figure 5. Note that, in the proposed ex-

ample, there is only one outgoing transition from an

adaptation process to a Cloud node tier (except for

the adding/removing the social login service that is

linked to three social networking services); in a more

realistic scenario involving a variability of alterna-

tive Cloud technologies for realizing a speciﬁc Cloud

node tier, there would be different outgoing transi-

tions with different costs.

The evolution event initiating the adaptation is an

event calendar, for example Christmas days begin-

ning (or Black Fridays). Coherently with the evolu-

Towards a Goal-oriented Approach to Adaptable Re-deployment of Cloud-based Applications

257

Figure 5: AG for the e-commerce application scalability scenario.

tion needs, the adaptation goal is the pair (authentica-

tion variation, authentication variation) to add/remove

a new social login service to the application. To ad-

dress the goal, in the AG in Figure 5 there are different

paths that can be followed depending on the differ-

ent cloud social networking services and their costs

(e.g., utilization-level/serviceability). The Adapt al-

gorithm selects the minimum cost path and therefore

determines the GAS shown in Figure 6.

This originating goal may in turn increase work-

load signiﬁcantly, thus generating new adaptation

goals related to the performance of the application

that need to be managed by one or more further adap-

tion processes. In particular, in a ﬁrst period the num-

ber of concurrent users is 100

and when the con-

current users increases, for example to 300, affect-

ing the application performance (performance varia-

tion), a vertical scaling process is selected by increas-

ing the capacity of the load balancer caching and of

the server’s message queues. The target goal is (users

requests variation, performance variation). The re-

sulting GAS extracted for this goal can be intuitively

derived from Figure 5.

If the number of users increases further, e.g. to

500, and saturates the Apache and Tomcat tiers (per-

formance variation), horizontal scaling is triggered

and one Apache and two Tomcats servers are added.

When the number of concurrent users increases fur-

ther the adaptation cycle repeats. In contrast, when

this number decreases, the application is scaled down

The values in the example are used only for illustra-

tion purposes. Realistic workload measures can be obtained

through monitoring systems based on statistical analysis

and on the amount of impact that various tuning parame-

ters produce on the application performance.

by removing idle servers and reducing the capacity of

the cache and message queues.

Data-intensive jobs are also monitored and if the

number of trafﬁc data per user increases stressing the

data tier (DB performance variation), a vertical scal-

ing of the database tier is ﬁrst executed by adding re-

sources to the MySQL master server. Further work-

load increasing that affects the DB performance re-

quires horizontal DB scaling by enabling the mas-

ter/slaves conﬁguration with data replication.

Once a triggering event occurs, the customiza-

tion of the application-speciﬁc AG and the compo-

sition of the adaptation processes (construction of the

GAS) are completed within few milliseconds. From

the GAS, an adaptation plan may be generated by up-

dating the TOSCA description of the application and

re-deploying it on-the-ﬂy using the deployment ser-

vice of the Cloud platform provider. Technical details

needed to adapt the TOSCA description may be gen-

erated from accessory data attached to the AG nodes.

The adaptation of the TOSCA topology from an AG

model is out of the scope of this paper.

5 RELATED WORK

General purpose studies on adaptation based on QoS

optimization and balancing are available in the liter-

ature. The SeaClouds project focuses on the prob-

lem of how to deploy and manage, in an efﬁcient

and adaptive way, complex applications across mul-

tiple heterogeneous cloud platforms. A key in-

gredient in the proposal is the use of two OA-

SIS standards initiatives for cloud interoperability,

CAMP and TOSCA, which allow for: describing the

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

258

Figure 6: GAS extracted for the ﬁrst goal.

topology of user applications independently of cloud

providers; providing abstract plans; discovering, de-

ploying/reconﬁguring, and monitoring the applica-

tions independently of the peculiarities of the cloud

providers (Brogi et al., 2015).

A Self-adaptive hierarchical monitoring mecha-

nism for Clouds is proposed in (Katsaros et al., 2012),

where a multi-layered monitoring framework mea-

sures QoS at both application and infrastructure lev-

els. The framework targets trigger events for runtime

adaptability of resource provisioning estimation and

decision making.

Changed user needs, system intrusions or faults,

changing operational environment, resource variabil-

ity are among the main kinds of adaptation required

in Service Oriented Architectures. An automatic op-

timization process for adaptation of service-oriented

applications is proposed in (Mirandola et al., 2014).

The approach is based on trade-offs between func-

tional and extra-functional requirements. The pro-

posed methodology relies on heterogeneous service

assembly and open tools and runtime infrastructures

to process architectural models that are directly tight

to the real assembled components implementations

and their distributed deployment.

Optimal solutions for cloud layers when resource

allocation is needed and to support explicit coopera-

tion between layers is addressed in (Scandurra et al.,

2012) using Pareto multi-objective optimization.

All these approaches satisfactorily address adap-

tation at design and at maintenance time, but are less

ﬂexible than our one in coping with evolution needs

emerging at runtime.

Several frameworks are available for providing

more speciﬁc solutions to addressed problems.

c-Eclipse is an open-source Cloud Application

Management Framework through which users are

able to deﬁne the description, deployment and man-

agement of their cloud applications in a clean and in-

tuitive graphical manner (Sofokleous et al., 2014).

JCatascopia is a Monitoring System capable of

supporting a fully automated cloud resource provi-

sioning system with proven interoperability, scalabil-

ity and low runtime footprint (Trihinas et al., 2014).

Celar is a platform able to automatically scale ap-

plications deployed over a cloud infrastructure. Celar

allow Cloud developers to build efﬁcient services and

achieve high performance by elastically managing

the use of available resources (Giannakopoulos et al.,

2014).

The framework proposed by (Copil et al., 2013c)

is made up of the SYBL language (Copil et al., 2013b)

and the Mela service (Moldovan et al., 2013). For

the control of elasticity the framework use the control

mechanism detailed in (Copil et al., 2013a).

Both methods and tools analyzed in this state of

the art face adaptation from well-deﬁned perspectives

and propose solutions to speciﬁc need emerging in an

adaptation scenario. On the contrary, our work man-

ages adaptation goals as general evolution needs. As a

consequence, the proposed approach generates adap-

tation plans through a workﬂow which is indepen-

dent of the evolution need to address. This makes the

whole approach general enough to be implemented in

any monitoring and management cloud framework.

6 CONCLUSION

This paper proposes a goal-based approach to the

run-time selection and composition of adaptation pro-

cesses in cloud-based applications. The approach ex-

ploits a graph-model to generate and execute an adap-

tation plan on the basis of evolution needs emerging

at run-time in a scenario of interest. Such a plan is de-

rived from sub-graphs in the general model extracted

by a speciﬁcally proposed algorithm. The instantia-

tion of this generic approach in an e-commerce cloud

application is given as running example.

We are currently working at the full implementa-

tion of the proposed approach, so to proceed with the

evaluation of its feasibility in different scenarios in-

volving cloud-based applications. To this purpose, we

are combining open source tools such as those of the

OpenTOSCA initiative and cloud middleware soft-

ware stacks (like Openstack and Opscode Chef con-

ﬁguration management software) to develop a cloud

management framework supporting our approach and

evaluate an end-to-end realistic scenario. In partic-

ular, we are deﬁning a mapping from a graph-based

representation of an adaptation plan to a TOSCA-

based adaptation plan.

As future work, we want to extend our approach

on several directions. Essentially, we want to: cope

with the management of concurrent multiple goals;

investigate on the adoption of an imperative process-

ing model for deploying a TOSCA-based cloud ap-

plication through a workﬂow; study how to make the

Towards a Goal-oriented Approach to Adaptable Re-deployment of Cloud-based Applications

259

system dynamically perform architecture-based adap-

tation to meet run-time quality requirements (such as

availability, performance, resilience, and greenness).

Architecture tactics could support the realization of

this last aim (see, for example, the work in (Miran-

dola et al., 2014)), but only if embedded at design

time into the TOSCA cloud topology of the applica-

tion and enabled/disabled at run-time accordingly.

ACKNOWLEDGEMENTS

This work is supported in part by the EC H2020 pro-

gram, project EscudoCloud (644579), by the Apulia

Region initiative ”Future in Research”, and by the

PON MIUR Edoc@work 3.0.

REFERENCES

Andrikopoulos, V., Binz, T., Leymann, F., and Strauch, S.

(2013). How to adapt applications for the cloud envi-

ronment - challenges and solutions in migrating appli-

cations to the cloud. Computing, 95(6):493–535.

Binz, T., Breitenb

ucher, U., Kopp, O., and Leymann, F.

(2014). chapter TOSCA: Portable Automated Deploy-

ment and Management of Cloud Applications, pages

527–549. Springer, New York.

Brogi, A., Carrasco, J., Cubo, J., Nitto, E. D., Dur

an, F.,

Fazzolari, M., Ibrahim, A., Pimentel, E., Soldani, J.,

Wang, P., and D’Andria, F. (2015). Adaptive man-

agement of applications across multiple clouds: The

seaclouds approach. CLEI Electron. J., 18(1).

Brogi, A., Soldani, J., and Wang, P. (2014). Tosca in a

nutshell: Promises and perspectives. In Villari, M.,

Zimmermann, W., and Lau, K.-K., editors, Service-

Oriented and Cloud Computing, volume 8745 of

Lecture Notes in Computer Science, pages 171–186.

Springer Berlin Heidelberg.

Casale, G., Ardagna, D., Artac, M., Barbier, F., Nitto,

E. D., Henry, A., Iuhasz, G., Joubert, C., Merseguer,

J., Munteanu, V. I., Perez, J. F., Petcu, D., Rossi, M.,

Sheridan, C., Spais, I., and Vladuic, D. (2015). DICE:

quality-driven development of data-intensive cloud

applications. In 7th IEEE/ACM International Work-

shop on Modeling in Software Engineering, MiSE

2015, pages 78–83. IEEE.

Copil, G., Moldovan, D., Truong, H.-L., and Dustdar, S.

(2013a). Multi-level elasticity control of cloud ser-

vices. In Service-Oriented Computing, pages 429–

436. Springer.

Copil, G., Moldovan, D., Truong, H.-L., and Dustdar, S.

(2013b). Sybl: An extensible language for controlling

elasticity in cloud applications. In Cluster, Cloud and

Grid Computing (CCGrid), 2013 13th IEEE/ACM In-

ternational Symposium on, pages 112–119. IEEE.

Copil, G., Moldovan, D., Truong, H.-L., and Dustdar, S.

(2013c). Sybl+ mela: Specifying, monitoring, and

controlling elasticity of cloud services. In Service-

Oriented Computing, pages 679–682. Springer.

Dijkstra, E. W. (1959). A note on two problems in connex-

ion with graphs. Numerische Mathematik, 1(1):269–

271.

Dubois, D. J., Valetto, G., Lucia, D., and Nitto, E. D.

(2015). Mycocloud: Elasticity through self-organized

service placement in decentralized clouds. In 8th

IEEE International Conference on Cloud Computing,

CLOUD 2015, pages 629–636. IEEE.

Giannakopoulos, I., Papailiou, N., Mantas, C., Konstanti-

nou, I., Tsoumakos, D., and Koziris, N. (2014). Celar:

automated application elasticity platform. In IEEE In-

ternational Conference on Big Data (Big Data), pages

23–25. IEEE.

Katsaros, G., Kousiouris, G., Gogouvitis, S. V., Kyriazis,

D., Menychtas, A., and Varvarigou, T. A. (2012). A

self-adaptive hierarchical monitoring mechanism for

clouds. Journal of Systems and Software, 85(5):1029–

1041.

Lehrig, S., Eikerling, H., and Becker, S. (2015). Scala-

bility, elasticity, and efﬁciency in cloud computing:

a systematic literature review of deﬁnitions and met-

rics. In Proc. of the 11th International ACM SIG-

SOFT Conference on Quality of Software Architec-

tures, QoSA’15 (part of CompArch 2015), pages 83–

92. ACM.

Mirandola, R., Potena, P., and Scandurra, P. (2014). Adap-

tation space exploration for service-oriented applica-

tions. Sci. Comput. Program., 80:356–384.

Moldovan, D., Copil, G., Truong, H.-L., and Dustdar, S.

(2013). Mela: Monitoring and analyzing elasticity of

cloud services. In Cloud Computing Technology and

Science (CloudCom), 2013 IEEE 5th International

Conference on, volume 1, pages 80–87. IEEE.

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

Capilla, R. (2012). Adapting cloud-based applications

through a coordinated and optimized resource alloca-

tion approach. In CLOSER 2012 - Proceedings of

the 2nd International Conference on Cloud Comput-

ing and Services Science, pages 355–364. SciTePress.

Sofokleous, C., Loulloudes, N., Trihinas, D., Pallis, G.,

and Dikaiakos, M. D. (2014). c-eclipse: An open-

source management framework for cloud applica-

tions. In Euro-Par 2014 Parallel Processing, pages

38–49. Springer.

Trihinas, D., Pallis, G., and Dikaiakos, M. D. (2014).

Jcatascopia: monitoring elastically adaptive applica-

tions in the cloud. In Cluster, Cloud and Grid Com-

puting (CCGrid), 2014 14th IEEE/ACM International

Symposium on, pages 226–235. IEEE.

Wettinger, J., Breitenb

ucher, U., and Leymann, F. (2015).

Compensation and convergence - comparing and com-

bining deployment automation approaches. Int. J. Co-

operative Inf. Syst., 24(3).

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

260