A Model-based Architecture for Autonomic and Heterogeneous Cloud

Systems

Hugo Bruneliere

, Zakarea Al-Shara

2, ∗

, Frederico Alvares

, Jonathan Lejeune

and Thomas Ledoux

NaoMod Team (LS2N-CNRS), IMT Atlantique, Nantes, France

Berger-Levrault, Montpellier, France

EasyVirt, Nantes, France

REGAL Team (Inria & LIP6-CNRS), Sorbonne Universities - UPMC, Paris, France

STACK Team (Inria & LS2N-CNRS), IMT Atlantique, Nantes, France

frederico.alvares@easyvirt.com, jonathan.lejeune@lip6.fr

Keywords:

Cloud Computing, Autonomic Computing, Modeling, Heterogeneity, Interoperability, Constraints.

Abstract:

Over the last few years, Autonomic Computing has been a key enabler for Cloud system’s dynamic adapta-

tion. However, autonomously managing complex systems (such as in the Cloud context) is not trivial and may

quickly become fastidious and error-prone. We advocate that Cloud artifacts, regardless of the layer carrying

them, share many common characteristics. Thus, this makes it possible to specify, (re)conﬁgure and moni-

tor them in an homogeneous way. To this end, we propose a generic model-based architecture for allowing

the autonomic management of any Cloud system. From a “XaaS” model describing a given Cloud system,

possibly over multiple layers of the Cloud stack, Cloud administrators can derive an autonomic manager for

this system. This paper introduces the designed model-based architecture, and notably its core generic XaaS

modeling language. It also describes the integration with a constraint solver to be used by the autonomic man-

ager, as well as the interoperability with a Cloud standard (TOSCA). It presents an implementation (with its

application on a multi-layer Cloud system) and compares the proposed approach with other existing solutions.

1 INTRODUCTION

Cloud Computing is becoming widely considered by

companies when building their systems. The number

of applications developed/deployed for/in the Cloud

is constantly increasing, even where software was tra-

ditionally not seen as central (e.g., cf. the quite re-

cent trend on Cloud Manufacturing (Xu, 2012)). The

Cloud market also provides many varied services,

platforms and infrastructures for customers to support

such Cloud-based systems (Narasimhan and Nichols,

2011). Thus, it becomes more complex for Cloud

providers and users to efﬁciently design, (re)conﬁgure

and monitor their solutions.

There are already several initiatives intending to

provide a more homogeneous Cloud management

support. OASIS TOSCA (OASIS, 2017) is a promis-

ing Cloud standard used in practice by IBM, Cloudify

or HP (for instance). It focuses on allowing an in-

∗

Zakarea Al-Shara had a postdoc position in the STACK

team, funded by Atlanstic2020 (CoMe4ACloud project).

teroperable representation of Cloud applications and

services, as well as their underlying infrastructures.

There is also CloudML (Ferry et al., 2014) that has

been developed, reﬁned and used in different Eu-

ropean projects notably (cf. ARTIST (Menychtas

et al., 2014), MODAClouds (Ardagna et al., 2012)

or PaaSage (Rossini, 2015)). Its objective is to al-

low modeling the provisioning, deployment, monitor-

ing and migration of Cloud systems. From a tech-

nology perspective, some open source environments

are gaining momentum. For example, tools from the

OpenStack (OpenStack Foundation, 2017) ecosystem

aim at providing more integrated compute, storage

and networking resources via commonly shared ser-

vices.

However, these solutions are still facing some

challenges. Firstly, the Cloud heterogeneity makes it

difﬁcult for these approaches to be applied system-

atically in all possible contexts. Indeed, Cloud sys-

tems may involve many resources having various and

varied natures (software and/or physical). Solutions

Bruneliere, H., Al-Shara, Z., Alvares, F., Lejeune, J. and Ledoux, T.

A Model-based Architecture for Autonomic and Heterogeneous Cloud Systems.

DOI: 10.5220/0006773002010212

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

ISBN: 978-989-758-295-0

201

to support in a similar way resources coming from

all the Cloud layers (e.g., IaaS, PaaS, SaaS) are thus

required. Secondly, Cloud systems are highly dy-

namic: clients can book/release “elastic” virtual re-

sources at any moment, according to given Service

Level Agreement (SLA) contracts. Solutions need to

reﬂect and support transparently this dynamicity/elas-

ticity, which is not trivial for systems involving many

different services. Thirdly, Cloud systems are becom-

ing so complex that they cannot be handled manu-

ally and efﬁciently. This concerns their conﬁgura-

tion and monitoring, but also their runtime behavior

to guarantee QoS levels and SLA contracts. This no-

tably involves decision-making and re-conﬁguration

to translate taken decisions into actual actions on the

systems. As a consequence, solutions coming with

an automated support for dealing with these activi-

ties can provide interesting beneﬁts (Krupitzer et al.,

2015).

We propose in this paper a generic model-based

architecture named CoMe4ACloud (Constraints and

Model Engineering for Autonomic Clouds)

. The

goal is to provide a generic and extensible solution

for the autonomic management of Cloud services, in-

dependently from the Cloud layer(s) they belong to

(i.e., XaaS, cf. Section 2). An initial version of a sup-

porting constraint model has already been proposed

by (Lejeune et al., 2017). However, it does not come

with a proper model-based architecture and a reusable

modeling language directly applicable to all Cloud

layers. Within this paper, we intend to address this

issue via the following contributions:

1. A model-based architecture for XaaS modeling in

order to support generic autonomic management;

• Including the connection with a constraint

solver (Choco (Jussien et al., 2008)) and

a partial mapping to/from a Cloud standard

(TOSCA) for interoperability with external so-

lutions;

2. A related XaaS core modeling language, possibly

supporting any of the possible Cloud layers;

3. An Eclipse-based tooling support, that has been

applied on a realistic multi-layer Cloud system.

The paper is structured as follows. In Section 2,

we introduce the general context and objectives of our

approach. In Section 3, we illustrate and motivate fur-

ther our work via a practical use case. Then, in Sec-

tion 4, we present the overall model-based architec-

ture we propose, including its relation with the Choco

constraint solver and mapping to/from the TOSCA

This work has been funded by Atlanstic2020, cf.

https://come4acloud.github.io for details.

Cloud standard. In Section 5, we detail our XaaS

generic modeling language as the core element of our

architecture. In section 6, we describe the correspond-

ing tooling support we built in Eclipse and how we

applied it in the context of our use case. In Section

7, we give more insights on the current status of our

approach. We discuss the related work in Section 8

before we conclude in Section 9.

2 BACKGROUND

Cloud services can be carried out by several different

layers of the Cloud stack. However, independently

from the layer(s) they rely on, they always share some

common characteristics (cf. Figure 1).

All Cloud architectures inherently expose and use

services hosted by resources within a multi-layer

stack. Each one of these services can play the role

of 1) consumer of other services in the Cloud stack

and/or 2) provider to other services in the Cloud stack

or eventually to end-users. Client applications can

consume services provided by a given SaaS resource.

This SaaS resource can consume services provided

by a given IaaS resource, which in turn can con-

sume some lower-level services offered by an energy

provider. In all cases, the objectives are very sim-

ilar: 1) Find an optimal balance between costs and

revenues by minimizing the cost of purchased ser-

vices and SLA violation penalties while maximiz-

ing revenues from provided services; 2) Comply with

all SLA and layer(s) internal constraints by having

a manager that can ﬁnd optimal layer conﬁgurations

based on these objectives.

We consider the generic notion of XaaS

(Anything-as-a-Service or Everything-as-a-

Service (Duan et al., 2015)) as a way to represent all

possible resources and layers in a Cloud stack as well

as the service-oriented relationships between them.

Any XaaS resource can both provide and consume

services to/from other resources/layers. It also comes

with constraints expressed in joint SLA contracts.

Moreover, frequent on-demand provisioning

makes Cloud environments susceptible to short-term

variations, often preventing them to be managed

Cloud Client

SaaS

IaaS

Energy as a Service

consume

produce

consume

produce

consume

produce

SLA

produce

consume

SLA

XaaS

Layer n+1

Layer n-1

Figure 1: Speciﬁc Cloud layers vs. generic XaaS.

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

202

manually. This is why Autonomic Computing

(AC) (Kephart and Chess, 2003) is very popular

in the Cloud community. AC provides architecture

references and guidelines intended to design Auto-

nomic Managers (AMs) that make Cloud systems

self-manageable. The main objective is to free Cloud

administrators of the burden of manually managing

them. Interestingly for us, a generic AM can also be

associated to the notion of XaaS in order to deal ho-

mogeneously with corresponding (re)conﬁgurations

(i.e., representations of real systems).

To realize this, it appears fundamental to be able to

model in a generic way such multi-layer Cloud archi-

tectures. Thus, we ﬁrst need to have a XaaS model-

ing language that allows describing all possible Cloud

topologies as well as corresponding actual system

conﬁgurations. Their core structure can be modeled

as directed acyclic graphs (DAGs): the number of ex-

isting nodes/resources is always ﬁnite, edges/services

have a stable orientation (consumer vs. producer),

and the usual top-down structure of the Cloud stack

prevents from having cycles. The language also has

to support the proper modeling of some constraints on

the deﬁned topologies (e.g., to reﬂect SLA contracts).

Modeling Cloud systems, their service-oriented inter-

actions and SLA contracts in an abstract way brings a

signiﬁcant advantage. Indeed, we can use such an ab-

stract model within a generic decision-making frame-

work to be part of our generic AM. In our case, we

used the help of a constraint solver (see Section 4.1).

As mentioned in Section 1, there are already some

existing Cloud modeling languages and approaches.

However, their intended scopes are slightly different

and their coverage may be limited regarding some

aspects, notably concerning the modeling of the re-

quired constraints. Thus, we made the choice of de-

signing our generic XaaS modeling architecture and

language covering the expression of constraints, as

needed for the associated AM. We compare our ap-

proach with the current related work in Section 8.

3 MOTIVATING EXAMPLE

To further motivate our architecture, and illustrate

later its application, we need a realistic cross-layer

Cloud system. The proposed use case encompasses

two related E-Learning systems from two distinct aca-

demic institutions. The end-users are students, fac-

ulty members and/or administrative staff who actually

consume the deployed E-learning services through a

web browser and/or mobile devices (phones, tablets,

etc.). Hence, the income load may drastically vary

within a business day, according to each client (in-

SaaS

Energy as a Service

Cloud Client

E-Learning

Brown Energy

Green Energy

IaaS

Large VM

Small VM

SLA: response time

SLA: availability

SLA: % green energy

Figure 2: E-Learning Cloud system - Case study.

stitution) activity. Let us consider a practical session

scheduled for a large group of students, possibly lo-

cated in different campuses. If this session requires

that students frequently interact with the E-learning

application, the service will suffer some overload sit-

uations during the session. As a consequence, the ap-

plication should be able to adapt itself by adjusting the

required compute capacity. The objective is to keep

the service response time at acceptable levels as de-

ﬁned in related SLA contracts. An overview of this

use case is depicted in Figure 2.

Students, as the main end-users of the offered E-

learning facilities, are the clients of a Software-as-a-

Service (SaaS) provider. At the upper level, this SaaS

provides a Cloud-based version of the Moodle learn-

ing management system

, i.e., an elastic Moodle. The

SaaS provider is a Infrastructure-as-a-Service (IaaS)

client, i.e., it needs compute resources in order to run

the E-learning services. Thus, at the lower level, a

IaaS provides the required services by means of avail-

able VMs. The datacenters of the IaaS provider need

electrical power in order to be able to operate. This

power can be obtained: 1) via equipments deployed

in-situ (i.e., on the campus) allowing for local pro-

duction of green energy (e.g., solar panels, windmills)

or 2) by electricity providers (brown energy) such as

Engie

in the form of Energy-as-a-Service (EaaS).

Hence, the IaaS should be capable of adapting itself in

response to clients arrivals/departures or requests/re-

leases of compute resources. Moreover, it should also

adapt to the local energy production and/or to the ﬂuc-

tuating prices of energy applied by EaaS providers.

In all cases, the goal is to autonomically re-

conﬁgure the system in order to have the best balance

between 1) costs, which are related to services con-

sumed/bought from providers (e.g., energy, compute

https://moodle.org

http://www.engie.com/en

A Model-based Architecture for Autonomic and Heterogeneous Cloud Systems

203

Topology

Metamodel

conforms to

Constraint

Program (SLA)

Configuration

Metamodel

Topology

Model t

conforms to

Configuration

Model c0

refers to

generation

Configuration

Model c1, cX

refers to

conforms to

Cloud

Expert

Cloud

Administrator

Runtime

Design time

Cloud

System s

represents

<<TOSCA>>

Topo./Config

. Model tcX’

TOSCA Tool

CoMe4ACloud

External Solution(s)

transformation

Figure 3: A model-based architecture.

resources) and 2) revenues, which refer to services of-

fered/sold to clients (e.g., E-learning service). A cou-

ple of XaaS model excerpts from our example (for the

IaaS level) are shown in Section 5, complementary re-

sources (e.g. models of the SaaS level) are also shown

and available in Section 6.2.

4 PROPOSED ARCHITECTURE

The proposed architecture heavily relies on the joint

use of complementary (meta)models as part of an it-

erative process (Atkinson and Kuhne, 2003). On the

one hand, a Topology Metamodel is dedicated to the

speciﬁcation of the different topologies (i.e., types)

of Cloud systems. This can be realized generically

for systems concerning any of the possible Cloud lay-

ers. On the other hand, a Conﬁguration Metamodel

is intended to the representation of actual conﬁgura-

tions (i.e., instances) of such systems. This is realized

by referring to a corresponding (previously speciﬁed)

topology. Once again, this metamodel is independent

from any particular Cloud layer and topology/type of

Cloud system. As shown in Figure 3, these two meta-

models are the cornerstones of the proposed architec-

ture and its core language (cf. Section 5).

In step (1) a topology model t is deﬁned manu-

ally by a Cloud expert at design time. It speciﬁes a

particular topology of system to be modeled and then

handled at runtime (e.g., a given type of IaaS). This

topology model notably includes the expression of the

corresponding SLAs. In step (2) this topology model

is used as the input of a code generator that translates

it into a Constraint Program (CP), thus encoding these

SLAs as constraints. The goal of this CP and related

constraint solver is to automatically compute a new

suitable system conﬁguration from an original one ac-

cording to the expressed constraints. In step (3) a ﬁrst

conﬁguration model c0 is initialized, either manually

by a Cloud administrator or automatically by the CP.

In step (4) the CP execution is performed according to

the current system state, represented as conﬁguration

model c0, and to the related set of constraints/SLAs

encoded in the CP. As a result, a new conﬁguration

model c1 is produced. Re-conﬁgurations can then oc-

cur whenever required (step (X)), via the re-execution

of the CP taking as input the current conﬁguration

model and producing as output a new updated one.

Thus, the different conﬁguration models (e.g., c0, c1

& cX) are representations of consecutive states of the

modeled Cloud system s at given points in time (see

more details in Section 7).

In parallel, the topology and conﬁguration models

can be transformed at any time into a partial equiva-

lent TOSCA models (step (Y)). Any TOSCA support-

ing tool can then be used to handle such models (step

(Z)). The available tooling support for this whole ar-

chitecture (including the features detailed in the two

next subsections) is presented in Section 6.1.

4.1 A Constraint Solver for an

Automomic Loop

As introduced before, the proposed architecture inte-

grates the use of a constraint solver (Choco (Jussien

et al., 2008) in our case) in order to realize the

decision-making of the autonomic loop allowing to

automatically compute system re-conﬁgurations. A

corresponding CP requires three different elements to

ﬁnd a solution (i.e., in our case a new conﬁguration): a

ﬁxed set of problem variables, a domain function (as-

sociating each variable to a domain) and a set of con-

straints. Our XaaS architecture and its two metamod-

els allow expressing these elements as required by the

constraint model we currently rely on (provided to us

by (Lejeune et al., 2017)).

From a Topology model, the implementation code

is automatically generated for the various node and re-

lationship types. This code also materializes the asso-

ciated constraints (expressing the related SLAs) from

this same model. For the sake of genericity, it actu-

ally calls only base pre-deﬁned classes extended by

the produced topology-speciﬁc classes. All this code

is required to actually instantiate the constraint model,

and for the solver to perform its analysis.

The instantiation is realized based on a given Con-

ﬁguration model. To this intent, a Conﬁguration

model is translated into a format that the generated

CP can process. This is then taken as input by the CP

that produces as output a new result providing an opti-

mal solution according to the considered constraints.

Finally, this result is translated back into a Conﬁgura-

tion model

We plan to replace this intermediate representation di-

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

204

4.2 A TOSCA Mapping for

Interoperability

For interoperability reasons, we have quite naturally

chosen to rely on the TOSCA standard from OA-

SIS (OASIS, 2017). However, the expressions/con-

straints we support in our architecture are not part of

the TOSCA scope and so cannot be natively modeled

with this standard. Because of that (cf. also Section

5.2 for complementary reasons), we decided to design

our own XaaS language and to establish a direct (par-

tial) mapping between our metamodels and TOSCA.

Note that a extension of TOSCA could also be envi-

sioned in the future to integrate of our constraint sup-

port into TOSCA.

The proposed mapping covers a large majority of

the structural aspects of our Topology and Conﬁgu-

ration metamodels. This way, we are able to auto-

matically initiate corresponding models from existing

TOSCA speciﬁcations. From an end-user perspective,

this allows saving time and reusing parts of the al-

ready available data. In the opposite way, we are also

able to export XaaS models as TOSCA speciﬁcations.

It is then possible to rely on external relevant TOSCA-

based solutions for dealing with various Cloud man-

agement activities (e.g., system monitoring).

5 CORE MODELING LANGUAGE

As explained before, our proposed architecture relies

on two metamodels forming a core XaaS modeling

language. In what follows, we detail the abstract syn-

tax of this language (i.e., the Topology and Conﬁgu-

ration metamodels). We also introduce the concrete

syntax we propose to facilitate its usage by Cloud

experts and system engineers. An implementation

of this language, including the metamodels and full

grammar, can be found from Section 6.1.

5.1 Abstract Syntax: Two Metamodels

As shown in Figure 4, the Topology metamodel cov-

ers 1) the general description of the structure of a

given topology and 2) the constraint expressions that

can be attached to the speciﬁed types of nodes and

relationships. Starting by the structural aspects, each

Cloud system’s Topology is named and composed of

a set of NodeTypes and corresponding Relationship-

Types that specify how to interconnect them. It can

also have some global constraints attached to it.

rectly by our Conﬁguration model in the future.

name : String

Topology

name : String

impactOfEnabling : Integer

impactOfDisabling : Integer

NodeType

name : String

type : String

impactOfUpdating : Integer

AttributeType

nodeTypes1..*

operator : ComparisonOperator

Constraint

Expression

0..1

expressions

value : Integer

IntegerValueExp

AttributeExp

operator : AlgebraicOperator

BinaryExp

operator : AggregationOperator

direction : DirectionKind

AggregationExp

direction : DirectionKind

NbConnectionExp

name : String

impactOfLinking : Integer

impactOfUnlinking : Integer

RelationshipType

relationshipTypes

0..*

attributeTypes

0..*

target

0..*

source 1

0..*

0..1

expressions

0..*

attributeType

0..*

inheritedType

0..1

ConstantAttributeType

Sum

Prod

Minus

Div

«enumeration»

AlgebraicOperator

Sum

Min

Max

«enumeration»

AggregationOperator

Predecessor/Source

Successor/Target

«enumeration»

DirectionKind

CalculatedAttributeType

0..1

constraints

0..*

0..1

expression1

Lesser

Greater

Equal

LesserOrEqual

GreaterOrEqual

«enumeration»

ComparisonOperator

0..1

constraints

0..*

0..1

constraints

0..*

expression : String

CustomExp

Figure 4: Topology metamodel - Design time.

Each NodeType has a name, a set of Attribute-

Types and can inherit from another NodeType. It

can also have one or several speciﬁc Constraints at-

tached to it. Cloud experts can declare the impact (in

terms of time, memory, price, etc.) of enabling/dis-

abling nodes at runtime (e.g., a given type of Physi-

cal Machine/PM node takes X seconds to be switched

on/off).

Each AttributeType has a name and value type. It

allows indicating the impact of updating related at-

tribute values at runtime. A ConstantAttributeType

stores a constant value at runtime, a CalculatedAt-

tributeType allows setting an Expression automati-

cally computing its value at runtime.

Any given RelationshipType has a name and de-

ﬁnes a source and target NodeType. It also al-

lows specifying the impact of linking/unlinking corre-

sponding nodes via relationships at runtime (e.g., mi-

grating a given type of Virtual Machine/VM node

from a type of PM node to another one can take sev-

eral minutes). One or several speciﬁc Constraints can

be attached to a RelationshipType.

A Constraint relates two Expressions according to

a predeﬁned set of comparison operators. An Expres-

sion can be a single static IntegerValueExpression or

an AttributeExpression pointing to an AttributeType.

A Model-based Architecture for Autonomic and Heterogeneous Cloud Systems

205

identifier : String

Configuration

identifier : String

activated : Boolean

Node

nodes

1..*

name : String

value : String

Attribute

identifier : String

constant : Boolean

Relationship

attributes

0..*

relationships

0..*

name : String

NodeType

type

0..*

name : String

Topology

topology

0..*

source

0..*

target

0..*

name : String

RelationshipType

type

0..*

Figure 5: Conﬁguration metamodel - Runtime.

It can be a NbConnectionExpression representing the

number of NodeTypes connected to a given NodeType

or RelationshipType (at runtime) as predecessor/suc-

cessor or source/target respectively. It can also be

an AggregationExpression aggregating the values of

an AttributeType from the predecessors/successors of

a given NodeType, according to a predeﬁned set of

aggregation operators. It can be a BinaryExpression

between two (sub)Expressions, according to a prede-

ﬁned set of algebraic operators. Finally, it can be

a CustomExpression using any available constraint/-

query language (e.g., OCL, XPath, etc.), the full ex-

pression simply stored as a string. Tools exploiting

corresponding models are then in charge of process-

ing such expressions.

As shown in Figure 5, the Conﬁguration part of

the language is simpler and directly refers to the

Topology one (cf. concepts with dashed lines). An

actually running Cloud system Conﬁguration is com-

posed of a set of Nodes and Relationships between

them.

Each Node has an identiﬁer and is of a given Node-

Type, as speciﬁed by the corresponding topology. It

also comes with a boolean value indicating whether it

is actually activated or not in the conﬁguration. This

activation can be reﬂected differently in the real sys-

tem according to the concerned type of node (e.g., a

given Virtual Machine (VM) is already launched or

not). A node contains a set of Attributes providing

name/value pairs, still following the speciﬁcations of

the related topology.

Each Relationship also has an identiﬁer and is of a

given RelationshipType, as speciﬁed again by the cor-

responding topology. It simply interconnects two al-

lowed Nodes together and indicates if the relationship

can be possibly changed (i.e., removed) over time,

i.e., if it is constant or not.

5.2 A YAML-like Concrete Syntax

We propose a notation for Cloud experts to quickly

specify their topologies and initialize related conﬁg-

urations. It also permits sharing such models in a

simple syntax to be directly read and understood by

Cloud administrators. We ﬁrst built an XML dialect

and prototyped an initial version. But we observed

that it was too verbose and complex, especially for

newcomers. We also thought about providing a graph-

ical syntax via simple diagrams. While this seems

appropriate for visualizing conﬁgurations, this makes

more time-consuming the topology creation/edition

(writing is usually faster than diagramming for Cloud

technical experts). Finally, we designed a lightweight

textual syntax covering both topology and conﬁgura-

tion speciﬁcations.

To provide a syntax that looks familiar to Cloud

users, we considered YAML and its TOSCA ver-

sion (OASIS, 2017) featuring most of the structural

constructs we needed (for topologies and conﬁgura-

tions). We started from this syntax and complemented

it with our language-speciﬁc elements, notably con-

cerning expressions and constraints as not supported

in YAML (cf. Section 5.1). We also ignored some

constructs from TOSCA YAML that are not required

in our language (e.g., related to interfaces, require-

ments or capabilities). We can still rely on other ex-

isting notations via our XaaS-TOSCA bridge (cf. Sec-

tion 4.2). For instance, by translating a conﬁguration

deﬁnition from our language to TOSCA, users can

beneﬁt from the GUI offered by external tooling such

as Eclipse Winery (Eclipse Foundation, 2017).

We show below how the Cloud experts and ad-

ministrators can write the IaaS layer of the motivating

example from Section 3.

Listing 1: Topology excerpt from our motivating example

(IaaS level).

1 Topology: E L e a r n ing - IaaS

3 node_types:

4 I n t e r n a lC o m p o n e nt :

5 PM :

6 derived_from: I n t e r n a l C o m p on e n t

7 properties:

8 im p a c t O f En a b l i n g : 40

9 im p a c t O f D i s a b li n g : 30

10 ...

11 VM :

12 derived_from: I n t e r n a l C o m p on e n t

13 ...

14 Cl u s te r :

15 derived_from: I n t e r n a l C o m p on e n t

16 properties:

17 constant Cl u st e r C o n s O n e C P U :

18 type: i n t e ge r

19 constant Cl u st e r C o n s O n e R A M :

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

206

20 type: i n t e ge r

21 constant Cl u s t e r C o n s M i nO n e P M :

22 type: i n t e ge r

23 variable Cl u s t e r N bC P U A c t i v e :

24 type: i n t e ge r

25 equal: Sum(Pred, PM . P m N b C P UA l l o c a t ed )

26 variable Cl u s t e r C u r C o n s u mp t i o n :

27 type: i n t e ge r

28 equal: C l u s te r C o n s M i n O n e P M * NbLink(Pred

) + Clu s t e r N b C P U A c ti v e *

Cl u s t e r C o n s O n eC P U +

Cl u s t e r C o n s O n eR A M * Sum(Pred, P M .

Pm S i z e R A M A l l o c a t e d )

29 Powe r :

30 derived_from: S e r v i c e P r o vi d e r

31 properties:

32 constant Po w e r C a p a c i t y :

33 type: i n t e ge r

34 variable Po w e r C u r C o n s u mp t i o n :

35 type: i n t e ge r

36 equal: Sum(Pred, Clust e r .

Cl u s t e r C u r C o n s u m p t i o n )

37 constraints:

38 Po w e r Cu r C o ns u m p ti o n less_or_equal:

Po w er C ap a c i t y

39 . . .

41 relationship_types:

42 V M _ T o _ P M :

43 valid_source_types: V M

44 valid_target_types: P M

45 P M _ T o _C l us t er :

46 . . .

47 C l us t e r _ T o _ P o w e r :

48 . . .

As shown on Listing 1, each node type comes with

its name and the node type it inherits from (if any).

Then, the Cloud expert describes its various attribute

types via the properties ﬁeld, following the TOSCA

YAML terminology. Similarly, for each relationship

type the Cloud expert gives its name and then indi-

cates its source and target node types.

Listing 2: Conﬁguration excerpt from our motivating exam-

ple (IaaS level).

1 Configuration:

2 identifier: El a rn i n g S y s te m _ 0

3 topology: ELearning - Ia a S

4 . . .

5 Node Po w e r 0 :

6 type: ELear n i n g - I a a S . P o w e r

7 activated: ’ t r u e ’

8 properties:

9 Po w er C ap a c i t y : 1500

10 Po w e r Cu r C o ns u m p ti o n : 0

11 . . .

12 Node Cl u s te r 0 :

13 type: ELear n i n g - I a a S . C l us t e r

14 activated: ’ t r u e ’

15 properties:

16 C l u s t e r C u r C o n s u m p ti o n : 0

17 Cl u s t er N b C P U A c t i v e : 0

18 Cl u s t e r C o n s O n eC P U : 1

19 Cl u s t e r C o n s O n eR A M : 0

20 C l u s t er C o n sM i n O ne P M : 5

21 . . .

22 Node PM0 :

23 type: ELear n i n g - I a a S . PM

24 activated: ’ t r u e ’

25 properties:

26 ...

27 . . .

28 Relationship P M _T o _C l u s t e r 0 :

29 type: ELearning - Ia a S . P M _T o _C l us t er

30 constant: true

31 source: PM0

32 target: Clu s t er 0

33 . . .

As explained before, expressions can be used to

indicate how to compute the initial value of an at-

tribute type. For instance, the variable ClusterCur-

Consumption of the Cluster node type is initialized at

conﬁguration level by making a product between the

value of other variables. Expressions can also be used

to attach constraints to a given node/relationship type.

For example, in the node type Power, the value of

the variable PowerCurConsumption has to be lesser

or equal to the value of the constant PowerCapacity

(at conﬁguration level).

As shown on Listing 2, for each conﬁguration the

Cloud administrator provides a unique identiﬁer and

indicates which topology it is relying on. Then, for

each actual node/relationship, its particular type is

explicitly speciﬁed by directly referring to the corre-

sponding node/relationship type from a deﬁned topol-

ogy. Each node describes the values of its different

attributes (calculated or set manually), while each re-

lationship describes its source and target nodes.

6 TOOLING SUPPORT &

APPLICATION

In this section, we brieﬂy describe the current imple-

mentation of our approach as well as its application

on a concrete scenario of adaptation.

6.1 Implementation

The proposed model-based architecture has been de-

signed to be deployed by Cloud experts and adminis-

trators in any context requiring some Cloud modeling

(e.g., independently from the autonomic aspects). To

this intent, they come with a corresponding tooling

support. Based on our own experience and the rich

available ecosystem, we decided to work on develop-

ing tooling based on Eclipse/EMF (Steinberg et al.,

2008) for our architecture and corresponding XaaS

language. This choice was reinforced by the fact that

A Model-based Architecture for Autonomic and Heterogeneous Cloud Systems

207

the Choco constraint solver (Jussien et al., 2008), a

reference solver in the Constraint community (and for

which we have access to a solid expert), has a com-

patible Java API. All the corresponding source code

is available from a Git repository

Constraint

Program

generates

TOSCA

Model mt

TOSCA

Metamodel

conforms to

Xtext

XaaS

Model mx

XaaS

Metamodels

conforms to

<<XaaS>>

Topo./Config.

elearning.xaas

<<TOSCA>>

Topo./Config.

elearning.xml

TOSCA Tool

ATL

Xtend

EMF/Ecore EMF/Ecore

Eclipse

Winery

Choco

CoMe4ACloud

Cloud

Expert /

Administrator

Figure 6: An Eclipse/EMF-based implementation.

As it can be seen from Figure 6, we made the

choice of using our language as the core repre-

sentation in our approach. The abstract syntax of

our XaaS language has been deﬁned via an Ecore

(meta)model (Steinberg et al., 2008), while its con-

crete syntax has been deﬁned via an Xtext gram-

mar (Bettini, 2016). Thanks to Xtext, we have also

been able to produce a dedicated editor coming with

useful features such as syntax highlighting, code com-

pletion, static checks, etc (cf. Figure 7). The connec-

tion with the constraint solver has been implemented

via corresponding code generator, in Xtend (Bettini,

2016), from our language to 1) the Java API provided

by Choco and 2) the XML format currently expected

by the CP program.

Figure 7: Screenshot of the developed Eclipse-based XaaS

modeling environment.

https://gitlab.inria.fr/come4acloud/xaas

In addition to this language and constraint sup-

port, we developed the required ATL (Jouault and

Kurtev, 2005) model-to-model transformations so that

our XaaS models can be partially transformed into

TOSCA ones (and vice-versa). Thus, it is possible to

beneﬁt from the tooling already offered by TOSCA-

based solutions (e.g., Eclipse Winery (Eclipse Foun-

dation, 2017) and its provided GUI for monitoring

conﬁgurations).

6.2 Application on our Motivating

Example

As a validation of the proposed technical solution, the

presented Eclipse tooling has been deployed based

on our motivating example (cf. Section 3). A com-

plete video-demonstration of this application is avail-

able online

. It shows 1) the design of the SaaS

layer with our XaaS modeling language, 2) the inter-

operability between the obtained XaaS models and a

TOSCA-based tool (Eclipse Winery (Eclipse Founda-

tion, 2017)) and 3) an illustration of a given adapta-

tion, i.e. a reconﬁguration, via our decision-making

architecture (based on the Choco solver).

In the scenario from the video-demo, the modeled

system (more precisely its SaaS-level) evolves from a

current state to another one, both represented as con-

ﬁguration models in our language. In the initial con-

ﬁguration model, described graphically in Figure 8,

a client WebApp is connected to a single instance of

the Moodle application. This application relies on a

Apache Web server and a MySQL server. Both are

running on a same worker node that is deployed on a

single Apache VM (from a unique provider).

In self-adaptative systems, there are two main

types of trigger than can launch a re-conﬁguration: 1)

planned/periodical ones (e.g., every 30 seconds) and

2) event-based ones (e.g., a new client subscribe to a

node, a monitored value changed in the system). In

the scenario presented here, we are in the second case

where a sudden increase of the Apache Web server’s

actual workload has been observed. This is going to

augment the application response time and so conse-

quently reduce the expected incomes and quality of

service. As a result of this observation, the automated

computation of a new conﬁguration (according to the

expressed SLAs) is triggered. The obtained reconﬁg-

uration is depicted in Figure 9.

In this new conﬁguration model, the Apache Web

server and the MySQL server are now running on two

distinct worker nodes. These nodes are also deployed

on two different Apache VMs, thus reducing the gen-

http://hyperurl.co/come4acloud

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

208

<<ClientWebApp>>

WebApp0

<<ApacheWebServer>>

WebServer0

<<MySQLServer>>

SQLServer0

<<MoodleApp>>

application0

<<Worker>>

worker0

<<VMProvider>>

provider0

<<ApacheVM>>

VM0

Figure 8: An initial conﬁguration from our motivating ex-

ample (SaaS level).

<<ClientWebApp>>

WebApp0

<<ApacheWebServer>>

WebServer0

<<MySQLServer>>

SQLServer0

<<MoodleApp>>

application0

<<Worker>>

worker1

<<VMProvider>>

provider0

<<ApacheVM>>

VM1

<<Worker>>

worker0

<<ApacheVM>>

VM0

Figure 9: A reconﬁguration from our motivating example

(SaaS level).

eral workload and improving the response time of the

whole system accordingly.

7 CURRENT STATUS

Within this paper, we presented in details the context

of our approach (cf. Sections 2 & 3) as well as its un-

derlying architecture (cf. Section 4) and core model-

ing language (cf. Section 5). Model-based principles

and techniques acted as the required framework for

bridging together the involved domains (i.e., Cloud

and Constraint) in a common integrated architecture.

The use of models, as core pivot representations to

be homogeneously used and shared both inside and

outside the proposed architecture, illustrates this in

practice. Modeling also acted as an enabler/facilita-

tor for designing, building and handling the architec-

ture’s core language. Indeed, having a cleaner lan-

guage deﬁnition and easier-to-maintain implementa-

tion is also an important aspect in our cross-domain

context. Thanks to this architecture and language, we

are able to provide a generic support for the auto-

mated reconﬁguration of multi-layer Cloud systems.

In coming Section 8, we compare our approach with

the state-of-the-art in this area.

The implementation we propose (cf. Section 6)

comes with other interesting challenges to tackle. We

list below the most relevant ones and give insights on

how we plan to address them in the future (or how we

are already working on it for some of them).

• Runtime. The required synchronization between

the XaaS models and the actual system they rep-

resent must be developed for each speciﬁc XaaS

target. To preserve genericity as much as possible,

we propose to implement a common adaptor inter-

face for each target running system. Thus, we are

currently working on building such a connector

for the OpenStack (OpenStack Foundation, 2017)

popular open source IaaS platform. At the SaaS

level, we are also developing an Amazon integra-

tion for benchmarking our motivating example.

• Scalability. We provide a generic system-

independent approach, so it has a certain price in

terms of the scalability of the related constraint

model/problem to be solved. However, we are

already able to ﬁnd solutions (i.e., new conﬁgu-

rations) quite efﬁciently (e.g., in 10 seconds) for

models of relatively important size (e.g., several

hundreds of nodes simulating virtual/physical ma-

chines). Other alternatives could be studied fur-

ther in order to improve performances even more:

for instance, we could consider hierarchizing the

constraints (modeling the SLAs) to avoid combi-

natorial explosion.

• Language V&V. The current version of our XaaS

modeling language comes with support for basic

syntactical validation. However, we currently do

not verify the correctness of the topologies and/or

conﬁguration described in our language. For ex-

ample, we do not provide features allowing to ver-

ify a priori that the Cloud expert is not expressing

A Model-based Architecture for Autonomic and Heterogeneous Cloud Systems

209

conﬂicting constraints in a given topology model.

Relying on some existing veriﬁcation solutions,

such a support could be added to our approach in

order to improve its general user experience.

• Integration with Cloud Standards. To go

further than the current interoperability with

TOSCA, we could propose the original features of

our core XaaS modeling language (e.g., the sup-

port for expressions/constraints) to the TOSCA

standardization group. This way, we could col-

lect their practical feedback which could eventu-

ally lead to a deeper integration of our approach

with the well-known and used TOSCA standard.

8 RELATED WORK

To discuss our approach, we identiﬁed common char-

acteristics we believe important for autonomic Cloud

(modeling) solutions. Table 1 compares our approach

with other existing work regarding different criteria:

• Genericity - The solution can support all Cloud

system layers (e.g., XaaS), or is speciﬁc to some

particular and well-identiﬁed layers;

• UI/Language - It can provide a proper user inter-

face and/or a modeling language intended to the

different Cloud actors;

• Interoperability - It can interoperate with other

existing/external solutions, and/or is compatible

with a Cloud standard (e.g., TOSCA);

• Runtime support - It can deal with runtime aspects

of Cloud systems, e.g., provide support for auto-

nomic loops and/or synchronization.

In the industrial Cloud community, there are many

existing multi-cloud APIs/libraries

8 9

and DevOps

tools

10 11

. APIs enable IaaS provider abstraction,

therefore easing the control of many different Cloud

services, and generally focus on the IaaS client side.

DevOps tools, in turn, provide scripting language and

execution platforms for conﬁguration management.

They rather provide support for the automation of the

conﬁguration, deployment and installation of Cloud

systems in a programmatical/imperative manner.

The Cloudify

platform overcomes some of these

limitations. It relies on a variant of the TOSCA

standard (OASIS, 2017) to facilitate the deﬁnition

of Cloud system topologies and conﬁgurations, as

Apache jclouds: https://jclouds.apache.org

Deltacloud: https://deltacloud.apache.org

Puppet: https://puppet.com

Chef: https://www.chef.io/chef/

http://cloudify.co

well as to automate their deployment and monitor-

ing. In the same vein, Apache Brooklyn

lever-

ages Autonomic Computing (Kephart and Chess,

2003) to provide support for runtime management

(via sensors/actuators allowing for dynamically mon-

itoring and changing the application when needed).

However, both Cloudify and Brooklyn focus on the

application/client layer and are not easily applica-

ble to all XaaS layers. Moreover, while Brook-

lyn is very handy for particular types of adaptation

(e.g., imperative event-condition-action ones), it may

be limited to handle adaptation within larger architec-

tures (i.e., considering many components/services and

more complex constraints). Our approach, instead,

follows a declarative and holistic approach which is

more appropriated for this kind of context.

The European project 4CaaSt proposed the

Blueprint Templates abstract language (Nguyen et al.,

2011) to describe Cloud services over multiple

PaaS/IaaS providers. The Cloud Application Model-

ing Language (Bergmayr et al., 2014) studied in the

ARTIST EU project (Menychtas et al., 2014) sug-

gests using proﬁled UML to model (and later de-

ploy) Cloud applications regardless of their underly-

ing infrastructure. Similarly, the mOSAIC EU project

proposes an open-source and Cloud vendor-agnostic

platform (Sandru et al., 2012). StratusML (Ham-

daqa and Tahvildari, 2015) provides another language

for Cloud applications dealing with different layers

to address the various Cloud stakeholders concerns.

All these approaches focus on enabling the deploy-

ment of applications (SaaS or PaaS) in different IaaS

providers. Thus they are quite layer-speciﬁc and do

not provide support for autonomic adaptation.

The MODAClouds EU project (Ardagna et al.,

2012) introduced some support for runtime man-

agement of multiple Clouds, notably by proposing

CloudML as part of the Cloud Modeling Framework

(CloudMF) (Ferry et al., 2013; Ferry et al., 2014).

As in our approach, CloudMF provides a generic

provider-agnostic model that can be used to describe

any Cloud provider as well as mechanisms for run-

time management by relying on Models@Runtime

techniques (Blair et al., 2009). In the PaaSage

EU project (Rossini, 2015), CAMEL (Achilleos

et al., 2015) extended CloudML and integrated other

languages such as the Scalability Rule Language

(SRL) (Domaschka et al., 2014). The framework Sa-

loon (Quinton et al., 2016) was also developed in this

same project, relying on feature models to provide

support for automatic Cloud conﬁguration and selec-

tion. However, contrary to our generic approach, in

these cases the adaptation decisions are delegated to

https://brooklyn.apache.org

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

210

Table 1: Comparing different Cloud (modeling) solutions (X for full support, ∼ for partial support).

Genericity UI / Interop- Runtime

Language erability support

APIs/DevOps X X

Cloudify X X X

Brooklyn X X ∼

4CaaSt (Nguyen et al., 2011) X

ARTIST-CAML (Bergmayr et al., 2014) X X

mOSAIC (Sandru et al., 2012) X ∼

Stratus ML (Hamdaqa and Tahvildari, 2015) X X

CloudMF (Ferry et al., 2013; Ferry et al., 2014) X ∼

PaaSage-CAML (Achilleos et al., 2015) X ∼

SRL (Domaschka et al., 2014) ∼ X X

Saloon (Quinton et al., 2016) X X

ARCADIA (Gouvas et al., 2016) X X ∼

Descartes (Kounev et al., 2016) X X

MODAClouds (Pop et al., 2016) X X

(Garc

ıa-Gal

an et al., 2014) X X X

CoMe4ACloud X X ∼ ∼

3rd-parties tools and tailored to speciﬁc problems/-

constraints (da Silva et al., 2014).

Recently, the ARCADIA EU project proposed a

framework to cope with highly adaptable distributed

applications designed as micro-services (Gouvas

et al., 2016). While in a very early stage and with

a different scope than us, it may be interesting to fol-

low this work in the future. Among other existing

approaches, we can cite the Descartes modeling lan-

guage (Kounev et al., 2016) based on high-level meta-

models to describe resources, applications, adaptation

policies, etc. A generic control loop is proposed on

top of it to fulﬁll some requirements for quality-of-

service and resource management. Quite similarly,

Pop et al., (Pop et al., 2016) propose an approach for

the deployment and autonomic management at run-

time on multiple IaaS. However both approaches are

targeting only Cloud systems structured as a SaaS de-

ployed in a IaaS, whereas our approach allows mod-

eling Cloud systems at any layer. In (Garc

ıa-Gal

et al., 2014), feature models are used to deﬁne the

conﬁguration space (along with user preferences) and

game theory is considered as a decision-making tool.

This work focuses on features that are selected in

a multi-tenant context, whereas our approach targets

the automated computation of SLA-compliant conﬁg-

urations in a cross-layer manner.

To the best of our knowledge, there is currently

no work that features at the same time genericity

w.r.t. the Cloud layers, interoperability with standards

(such as TOSCA), high-level modeling language sup-

port and some autonomic runtime management capa-

bilities. The proposed model-based architecture de-

scribed in this paper is a ﬁrst step in this direction.

9 CONCLUSION

The proposed architecture and related XaaS modeling

language intend to provide a generic solution for the

autonomous runtime management of heterogeneous

Cloud systems. To realize this, we notably rely on

Constraint Programming as a decision-making tool to

automatically obtain system conﬁgurations respecting

speciﬁed SLA contracts. A main objective of this pa-

per was to provide a suitable interface with our archi-

tecture, via its core XaaS modeling language, to both

Cloud experts and administrators. Another goal was

to have generic XaaS models that can possibly inter-

operate with standards (e.g., TOSCA).

In the future we intend to apply our approach to

other contexts somehow related to Cloud Computing,

such as in the domain of Fog Computing for instance.

This is expected to come with particular challenges

in terms of scalability notably. Thus, the deﬁned ar-

chitecture and modeling language will have to be re-

evaluated in the light of this new Fog context. We

foresee their needed evolution in order to be able to

efﬁciently model and support Fog characteristics such

as a higher geographic distribution, the diversity of

the involved resources/services, their reliability, etc.

Finally, we are aware that specifying constraints

for the considered systems and their SLAs can be

a difﬁcult and time-consuming activity. Moreover,

the quality of the produced contraints highly depends

on human knowledge and experience (e.g., from the

Cloud Experts/Administrators). To limit potential er-

rors and improve the efﬁciency of our approach, it

would be interesting to be able to exploit automati-

cally the historical data of the modeled systems. To

A Model-based Architecture for Autonomic and Heterogeneous Cloud Systems

211

this end, we plan to explore the possible use of some

Machine Learning techniques which could guide or

assist the constraint speciﬁcation process.

REFERENCES

Achilleos, A. P., Kapitsaki, G. M., Constantinou, E., Horn,

G., and Papadopoulos, G. A. (2015). Business-

Oriented Evaluation of the PaaSage Platform. In

IEEE/ACM UCC 2015, pages 322–326.

Ardagna, D., Nitto, E. D., Casale, G., Petcu, D., Mo-

hagheghi, P., Mosser, S., Matthews, P., Gericke, A.,

Ballagny, C., D’Andria, F., et al. (2012). MODA-

Clouds: A Model-driven Approach for the Design and

Execution of Applications on Multiple Clouds. In

MiSE@ICSE 2012, pages 50–56.

Atkinson, C. and Kuhne, T. (2003). Model-Driven Devel-

opment: a Metamodeling Foundation. IEEE Software,

20(5):36–41.

Bergmayr, A., Troya, J., Neubauer, P., Wimmer, M., and

Kappel, G. (2014). UML-based Cloud Application

Modeling with Libraries, Proﬁles, and Templates. In

2nd CloudMDE@MODELS 2014, pages 56–65.

Bettini, L. (2016). Implementing Domain-Speciﬁc Lan-

guages with Xtext and Xtend. Packt Publishing Ltd.

Blair, G., France, R. B., and Bencomo, N. (2009). Models@

run.time. IEEE Computer, 42:22–27.

da Silva, M. A. A., Ardagna, D., Ferry, N., and Prez,

J. F. (2014). Model-Driven Design of Cloud Ap-

plications with Quality-of-Service Guarantees: The

MODAClouds Approach. In SYNACS 2014, pages 3–

10.

Domaschka, J., Kritikos, K., and Rossini, A. (2014). To-

wards a Generic Language for Scalability Rules. In

ESOCC, pages 206–220.

Duan, Y., Fu, G., Zhou, N., Sun, X., Narendra, N. C., and

Hu, B. (2015). Everything as a Service (XaaS) on the

Cloud: Origins, Current and Future Trends. In IEEE

CLOUD 2015, pages 621–628.

Eclipse Foundation (2017). Winery project.

https://projects.eclipse.org/projects/soa.winery.

Ferry, N., Rossini, A., Chauvel, F., Morin, B., and Solberg,

A. (2013). Towards Model-Driven Provisioning, De-

ployment, Monitoring, and Adaptation of Multi-cloud

Systems. In IEEE CLOUD 2013, pages 887–894.

Ferry, N., Song, H., Rossini, A., Chauvel, F., and Solberg,

A. (2014). CloudMF: Applying MDE to Tame the

Complexity of Managing Multi-cloud Applications.

In IEEE/ACM UCC 2014, pages 269–277.

Garc

ıa-Gal

an, J., Pasquale, L., Trinidad, P., and Ruiz-

Cort

es, A. (2014). User-centric Adaptation of Multi-

tenant Services: Preference-based Analysis for Ser-

vice Reconﬁguration. In ACM SEAMS 2014, pages

65–74.

Gouvas, P., Fotopoulou, E., Zafeiropoulos, A., and Vas-

silakis, C. (2016). A Context Model and Poli-

cies Management Framework for Reconﬁgurable-by-

design Distributed Applications. Procedia Computer

Science, 97(Supplement C):122 – 125.

Hamdaqa, M. and Tahvildari, L. (2015). Stratus ML: A

Layered Cloud Modeling Framework. In IEEE IC2E

2015, pages 96–105.

Jouault, F. and Kurtev, I. (2005). Transforming Models with

ATL. In ACM/IEEE MODELS 2005, pages 128–138.

Jussien, N., Rochart, G., and Lorca, X. (2008). Choco: an

Open Source Java Constraint Programming Library.

In OSSICP@CPAIOR’08.

Kephart, J. O. and Chess, D. M. (2003). The Vision of Au-

tonomic Computing. IEEE Computer, 36(1):41–50.

Kounev, S., Huber, N., Brosig, F., and Zhu, X. (2016).

A Model-Based Approach to Designing Self-Aware

IT Systems and Infrastructures. IEEE Computer,

49(7):53–61.

Krupitzer, C., Roth, F. M., VanSyckel, S., Schiele, G., and

Becker, C. (2015). A Survey on Engineering Ap-

proaches for Self-adaptive Systems. Pervasive and

Mobile Computing, 17:184–206.

Lejeune, J., Alvares, F., and Ledoux, T. (2017). Towards

a Generic Autonomic Model to Manage Cloud Ser-

vices. In CLOSER 2017.

Menychtas, A., Konstanteli, K., Alonso, J., Orue-

Echevarria, L., Gorronogoitia, J., Kousiouris, G.,

Santzaridou, C., Bruneliere, H., Pellens, B., Stuer,

P., Strauss, O., Senkova, T., and Varvarigou, T.

(2014). Software Modernization and Cloudiﬁca-

tion Using the ARTIST Migration Methodology and

Framework. Scalable Computing : Practice and Ex-

perience, 15(2):131–152.

Narasimhan, B. and Nichols, R. (2011). State of Cloud Ap-

plications and Platforms: The Cloud Adopters’ View.

IEEE Computer, 44(3):24–28.

Nguyen, D. K., Lelli, F., Taher, Y., Parkin, M., Papazoglou,

M. P., and van den Heuvel, W.-J. (2011). Blueprint

Template Support for Engineering Cloud-based Ser-

vices. In ServiceWave 2011, pages 26–37.

OASIS (2017). Topology and Orchestration Spec-

iﬁcation for Cloud Applications (TOSCA) and

YAML (TOSCA Simple Proﬁle). https://www.oasis-

open.org/standards.

OpenStack Foundation (2017). OpenStack

Open Source Cloud Computing Software.

https://www.openstack.org.

Pop, D., Iuhasz, G., Craciun, C., and Panica, S. (2016).

Support Services for Applications Execution in Multi-

clouds Environments. In ICAC 2016, pages 343–348.

Quinton, C., Romero, D., and Duchien, L. (2016). SA-

LOON: a Platform for Selecting and Conﬁguring

Cloud Environments. Software: Practice and Expe-

rience, 46:55–78.

Rossini, A. (2015). Cloud Application Modelling and Ex-

ecution Language (CAMEL) and the PaaSage Work-

ﬂow. In ESOCC 2015, pages 437–439.

Sandru, C., Petcu, D., and Munteanu, V. I. (2012). Build-

ing an Open-Source Platform-as-a-Service with Intel-

ligent Management of Multiple Cloud Resources. In

IEEE UCC 2012, pages 333–338.

Steinberg, D., Budinsky, F., Merks, E., and Paternostro, M.

(2008). EMF: Eclipse Modeling Framework. Pearson

Education.

Xu, X. (2012). From Cloud Computing to Cloud Manufac-

turing. Robotics and Computer-Integrated Manufac-

turing, 28(1):75–86.

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

212