Towards the Modelling of Adaptation Rules and Histories for

Multi-Cloud Applications

Kyriakos Kritikos

, Chrysostomos Zeginis

, Eleni Politaki

and Dimitris Plexousakis

1,2

ICS-FORTH, Heraklion, Crete, Greece

Department of Computer Science, University of Crete, Heraklion, Crete, Greece

Keywords:

Adaptation, Execution, History, Rule, Meta-model, DSL.

Abstract:

Currently, there is a move towards adopting multi-clouds due to their main beneﬁts, including vendor lock-in

avoidance and optimal application realisation via different cloud services. However, such multi-cloud appli-

cations face a new challenge related to the dynamicity and uncertainty that even a single cloud environment

exhibits. As such, they cannot deliver a suitable service level to their customers, resulting in SLA penalty

costs and application provider reputation reduction. To this end, we have previously proposed a cross-level

and multi-cloud application adaptation architecture. Towards realising this architecture, this paper proposes

two extensions of the CAMEL language allowing to specify advanced adaptation rules and histories. Such

extensions not only enable to cover cross-level application adaptation by executing adaptation workﬂows but

also to progress such an adaptation to address both the application and exploited cloud services evolution.

1 INTRODUCTION

Cloud computing has revolutionized the way appli-

cations are developed, deployed and provisioned. Its

wide adoption has led to a proliferation of cloud ap-

plications and services. Such applications were either

migrated to the Cloud or were developed from scratch

by adopting existing or new technologies. The suc-

cess of this computing paradigm is mainly due to the

beneﬁts it delivers, including cost reduction, ﬂexible

resource management and resource elasticity allow-

ing applications to scale on demand as needed.

Various providers have rushed to offer cloud ser-

vices and platforms. The bigger from those providers

have also attempted to lock-in cloud users by offer-

ing certain technologies, platforms as well as extra,

added-value secondary services. This has led towards

adapting multi-clouds both at the research and in-

dustry level. The application deployment at multiple

clouds is quite promising as it enables to avoid the

vendor lock-in while it also brings additional bene-

ﬁts, including the selection of the best cloud services

to optimally realise an application according to its re-

quirements and the increase of the application secu-

rity level via adopting different security services.

However, multi-cloud applications face a novel

challenge related to the dynamicity and uncertainty

inherent even in a single cloud. This jeopardises an

application’s ability to keep up with its promises by

delivering a suitable service level to its customers.

Such a challenge is further hardened by the fact that

an application can be realised by different cloud ser-

vices types in different abstraction levels. Thus, an

application is vulnerable to the quality level varia-

tion of such services. Further, the dynamicity aspect

should not be neglected. Both services and applica-

tion requirements can evolve over time. As such, even

if a suitable way to adapt an application is discovered,

it can be invalidated over time due to this dynamicity.

To close this gap, we have already proposed (Kri-

tikos et al., 2017) an architecture of an advanced,

cross-level and multi-cloud application adaptation

framework. Such a framework will exhibit the follow-

ing features: (a) semi-automatically infer new adap-

tation rules (Zeginis et al., 2015) by considering the

application structure and the dependencies at the dif-

ferent abstraction levels; (b) dynamically transform

such rules into adaptation workﬂows that can be en-

acted via workﬂow execution engines; (c) dynami-

cally evolve adaptation rules based on their execution

history, performance and successability in completely

addressing an actual event (“problematic situation”)

that has caused their execution. All these features are

currently being implemented to realise our vision.

This paper attempts to provide support to this on-

going realisation by proposing two meta-model ex-

300

Kritikos, K., Zeginis, C., Politaki, E. and Plexousakis, D.

Towards the Modelling of Adaptation Rules and Histories for Multi-Cloud Applications.

DOI: 10.5220/0007706503000307

In Proceedings of the 9th International Conference on Cloud Computing and Services Science (CLOSER 2019), pages 300-307

ISBN: 978-989-758-365-0

tensions to the CAMEL state-of-the-art cloud mod-

elling language (Rossini et al., 2015). The ﬁrst exten-

sion focuses on the modelling of advanced adaptation

rules. Such a modelling is quite rich as it re-uses ele-

ments from Complex Event Pattern (CEP) languages,

like the Esper’s

one, to specify complex event pat-

terns as logical or time-based compositions of sim-

pler events. Further, to complete the adaptation rule

speciﬁcation, it enables mapping such events patterns

to workﬂow-language-independent adaptation work-

ﬂows, including actions at any possible abstraction

level (infrastructure, platform, software and work-

ﬂow). To the best of our knowledge, no other meta-

model or language (Song et al., 2013; Erbel et al.,

2018; Marquezan et al., 2014; Lushpenko et al., 2015)

has the right expressivity level to specify such adap-

tation rules. Our contribution beneﬁts the ﬁrst two

features of the envisioned adaptation framework. Es-

pecially, the workﬂow language independence offers

implementation ﬂexibility as our adaptation frame-

work could re-use any workﬂow engine, specialised

in the use of a certain workﬂow language.

The second meta-model extends CAMEL’s execu-

tion sub-DSL to capture not only application execu-

tion but also adaptation histories by explicating which

adaptation actions were performed under which adap-

tation rule and how well they addressed the respective

problematic event according to which performance

level. This contribution beneﬁts the 3rd adaptation

framework feature. First, as it enables analysing the

suitability of single and composite adaptation actions

(i.e., workﬂows), thus allowing their prospective sub-

stitution when the need arises. It can also identify

places for adaptation behaviour improvement by de-

tecting situations where all automatically-generated

alternative adaptation workﬂows for the same event

are not so performant or suitable any more. As

such, this meta-model well covers our goal to (semi-

)automatically evolve the application adaptation be-

haviour over time to cope with permanent changes in

both the services being exploited and the application

requirements. This second paper contribution is novel

as we are not aware of any approach able to record the

cloud application adaptation history.

The rest of the paper is structured as follows. Next

section introduces our envisioned adaptation frame-

work architecture. Section 3 elaborates on the adap-

tation meta-model proposed. Section 4 explicates

the extension performed over CAMEL’s execution

meta-model. Section 5 provides an example use case

utilised to showcase the added-value of the two meta-

models proposed. Finally, the last section concludes

the paper and draws directions for further research.

www.espertech.com/esper/

2 MULTI-CLOUD APPLICATION

ADAPTATION FRAMEWORK

We have already proposed a holistic multi-cloud ap-

plication adaptation framework, depicted in Fig. 1.

This framework, currently under implementation, ex-

hibits the following features: (a) enables inferring

new from existing adaptation rules; (b) transforms

such rules into adaptation workﬂows that can be exe-

cuted by workﬂow engines; (c) dynamically changes

adaptation workﬂows mapping to problematic events

to better address them and thus evolve application

adaptive behaviour; (d) enables editing adaptation

rules, quite handy when automatically generated rules

need adjustment or for rapidly dealing with cases not

covered by the existing adaptation rule set; (e) enables

browsing the adaptation history to check the success-

fulness of adaptation rules. All these ﬁve features are

enabled by the paper’s two contributions.

In the sequel, we shortly explain the adaptation

framework components and their interactions. The

Adaptation UI enables editing adaptation rules, enact-

ing them (e.g., manual rules to rapidly react to unan-

ticipated situations), and visualising both the applica-

tion adaptation history and its analysis. The analysis

results could then be approved by the expert to evolve

the application adaptation behaviour, if needed.

Any adaptation rule kind, edited or automatically

generated or enacted, passes via the Transformer, re-

sponsible for: (a) transforming the rules in CAMEL

into the format expected by the Rule Engine; (b) trans-

forming the adaptation workﬂow part of enacted rules

into the language expected by the Adaptation Engine.

The Rule Engine enables the enactment path of

rules. It takes as input monitoring events, retrieved

from the Monitoring Framework, and checks which

are the adaptation rule(s) triggered by them. Upon a

rule triggering, the Transformer is informed to enact

its adaptation workﬂow. Internally, the Rule Engine

utilises a Rule Base for adaptation rule storage.

Once the enacted rules’ workﬂow is transformed,

it must be concretised. The main rationale is that

the adaptation framework capabilities can be enriched

over time such that a certain adaptation task could

be realised by two or more alternatives. As such,

the Concretiser, based on user requirements and pref-

erences, attempts to solve a constraint optimisation

problem to support the selection of the best possible

adaptation task alternatives globally.

A concretised adaptation workﬂow can be then

executed by the Adaptation Engine, taking the form

of a workﬂow execution engine. This engine also

stores information about the adaptation workﬂow ex-

ecution in the Model Repository (a placeholder for all

Towards the Modelling of Adaptation Rules and Histories for Multi-Cloud Applications

301

Figure 1: The envisioned adaptation framework architecture.

CAMEL models produced and manipulated) by us-

ing CAMEL’s execution meta-model extension. The

workﬂow execution relies on using level-speciﬁc ser-

vices (e.g., WfaaS/SaaS adaptation service) repre-

senting service-based realisations of adaptation tasks.

The Adapter generates new or adapts existing

adaptation rules by analysing the adaptation history.

New rules are semi-automatically generated via our

previous work (Zeginis et al., 2015), which combines

the event patterns discovered with all possible combi-

nations of adaptation tasks able to address them.

3 ADAPTATION META-MODEL

CAMEL originally covered the adaptation of multi-

cloud applications via its scalability meta-model, ded-

icated to the capturing of scalability rules in form of

mappings from events to scaling actions.

Events (see Fig. 2) could be simple or composite.

Simple events were speciﬁed via metric conditions.

Composite events were speciﬁed as event patterns by

applying time-based (e.g., PRECEDES) and logical

operators (e.g., AND) over simpler events, thus actu-

ally representing an event tree or hierarchy.

Scaling actions were distinguished into horizontal

and vertical. Horizontal scaling actions were speci-

ﬁed by indicating the number of instances to be added

or removed for an application component. Vertical

scaling actions were specifying the VM to be scaled

and the respective update in the size or number of cer-

tain VM features like the number of cores.

To cover the whole adaptation possibilities of a

multi-cloud application at different abstraction levels,

CAMEL was extended (see Fig. 3) to transform its

scalability meta-model to an adaptation one.

3.1 Adaptation Rules and Strategies

The meta-model’s topmost element is Adaptation-

Model, acting as a container for all adaptation-related

elements. The meta-model’s key concept is Adapta-

tionRule, mapping events to adaptation actions.

In essence, there can be multiple rules able to con-

front a problematic situation, i.e., an event; so, an

adaptation system must choose the best from them.

This choice can be reduced to selecting the rule with

highest priority, i.e., a dynamically-modiﬁable at-

tribute. This means that an already selected rule might

be unsuitable for selection in the near future as it

might not have a sufﬁcient successability level or a

better rule is discovered that more completely ad-

dresses the respective event. An AdaptationStrategy

encapsulates all rules confronting such an event. The

collection of all adaptation strategies then represents

an application’s current adaptive behaviour as well as

the way such a behaviour can evolve over time.

3.2 Adaptation Tasks

Event speciﬁcation has not been modiﬁed in the new

CAMEL version. However, the scaling actions were

subsumed by an adaptation task, that can be incorpo-

rated within adaptation workﬂows to confront prob-

lematic situations. Such a task can be simple or com-

posite. A simple task maps to executing a level-

speciﬁc action, while a composite task can be seen as

an adaptation workﬂow, i.e., a composition of (sim-

pler) adaptation tasks whose execution is controlled

by well-known control ﬂow constructs.

CLOSER 2019 - 9th International Conference on Cloud Computing and Services Science

302

BinaryEventPattern

lowerOccurrenceBound : EInt = 0

upperOccurrenceBound : EInt = 0

operator : BinaryPatternOperatorType = AND

BinaryPatternOperatorType

AND

XOR

PRECEDES

REPEAT_UNTIL

Event

name : EString

HorizontalScaling

count : EInt = 0

NonFunctionalEvent

isViolation : EBoolean = false

Scaling

SimpleEvent

Timer

name : EString

type : TimerType = WITHIN

timeValue : EInt = 0

maxOccurrenceNum : EInt

TimerType

INTERVAL

WITHIN

WITHIN_MAX

UnaryEventPattern

occurrenceNum : EInt = 0

operator : UnaryPatternOperatorType = EVERY

UnaryPatternOperatorType

EVERY

NOT

WHEN

REPEAT

VerticalScaling

CPUUpdate : EDouble = 0.0

networkUpdate : EInt = 0

memoryUpdate : EInt = 0

coreUpdate : EInt = 0

storageUpdate : EInt = 0

ioUpdate : EInt = 0

FunctionalEvent

functionalType : EString

Component

EventPattern

[0..1] leftEvent

[0..1] rightEvent

[1..1] event

[1..*] components

[0..1] component

[0..1] timer

[1..1] vm

Figure 2: The representation of events in CAMEL.

AdaptationRule

name : EString

priority : EFloat = 0.0

AdaptationStrategy

name : EString

AdaptationTask

ComponentConfiguration

ComponentDeployment

ComponentReconfiguration

ConfigureType : ConfigureType = Configure

ComponentReDeployment

ComponentUnDeployment

CompositeAdaptationTask

ConditionalAdaptationTask

ConfigureType

START

STOP

CrossCutting

IaasAction

type : IaasActionType = STARTUP

IaasActionType

STARTUP

RESTART

Migration

allInstances : EBoolean = false

ParallelAdaptationTask

Reporting

message : EString

recipients : EString

protocol : EString

Scaling

SequentialAdaptationTask

ServiceReplacement

SimpleAdaptationTask

SwitchAdaptationTask

TaskAddition

TaskDeletion

TaskModification

enclosingElement : EString

position : EInt = 0

TaskReplacement

ValueToTask

WorkflowAdaptationTask

workflowId : EString

level : AdaptationLevel = CLASS

WorkflowRecomposition

startElement : EString

endElement : EString

subWorkflowSpecification : EString

Component

CONFIGURE

SHUTDOWN

AdaptationLevel

CLASS

INSTANCE_PERMANENT

INSTANCE_NOT_PERMANENT

MetricFormulaParameter

name : EString

[1..1] task

[1..*] rules

[2..*] valueToTask

[1..1] task

[1..*] components

[1..1] hostingComponent

[0..*] components

[1..1] from

[0..1] to

[1..1] previousService

[1..1] newService

[0..1] deployed

[1..*] adaptationTasks

[1..1] vm

[1..1] formulaParameter

Figure 3: The adaptation meta-model in CAMEL.

3.2.1 Composite Adaptation Tasks

A composite task can be seen as a tree containing

tasks with lower complexity. To simulate the four

main types of basic control ﬂows that can participate

in any workﬂow kind, we have created respective sub-

concepts of the CompositeAdaptationTask concept.

A SequentialAdaptationTask represents a se-

quence of adaptation tasks, while a ParallelAdapta-

tionTask a parallel execution of tasks. On the other

hand, a ConditionalAdaptationTask relates to a con-

ditional construct predicated over a certain event ref-

erenced. The occurrence of that event leads to ex-

ecuting the ﬁrst task referenced by this composite

task, while its non-occurrence the second referenced

task. For a conditional branch with multiple alterna-

tives, a SwitchAdaptationTask needs to be supplied,

which relates to a certain MetricFormulaParameter,

i.e., a metric or a metric formula. In each case, mul-

tiple values can be produced by monitoring this met-

Towards the Modelling of Adaptation Rules and Histories for Multi-Cloud Applications

303

ric or computing this formula that have to be mapped

(see ValueToTask concept) to the respective adapta-

tion tasks that need to be executed.

3.2.2 Simple Adaptation Tasks

A simple adaptation task is sub-classed, according to

the (abstraction) level it pertains, to other concepts

with the exception of the Cross-Cutting abstract con-

cept, representing cross-cutting adaptation actions.

IaaSAction covers all possible actions (startup,

shutdown and restart) at the IaaS level by referring to

the VM to be adapted and the action type that can be

performed on it (see IaaSActionType enumeration).

At the SaaS level, adaptation tasks are encapsu-

lated by the abstract ComponentConﬁguration con-

cept which covers the conﬁguration of one or more

SaaS. This task can then be further distinguished into

more concrete conﬁguration tasks which include:

• ComponentDeployment: indicates that the SaaS

components referenced must be deployed in a

PaaS or IaaS component. Such an action could

be useful in the context of deploying components,

such as load balancers, only after the second in-

stance of an application component is created.

• ComponentUnDeployment: indicates that the

components referenced need to be undeployed

from their hosting component, also referenced.

Such a scenario could be useful in hybrid cloud

bursting, where the public VMs for a certain ap-

plication component are not needed any more.

• ComponentReDeployment: signiﬁes that the com-

ponents referenced must be redeployed. This

could be useful for migrating the components to

a new version, e.g., to address certain bugs.

• ComponentReconﬁguration: signiﬁes that the ref-

erenced components must be reconﬁgured by ei-

ther stopping, starting (e.g., to bypass the poten-

tial transient error occurred) or redeploying them

(e.g., when the error is not transient).

At the workﬂow level, WorkﬂowAdaptationTask

encapsulates all possible adaptation tasks.A workﬂow

adaptation task can be further distinguished into a

WorkﬂowRecomposition and TaskModication one.

A WorkﬂowRecomposition signiﬁes the need to re-

compose a workﬂow from the current execution point

until the ﬁnal workﬂow task by replacing its respec-

tive remaining content with a (sub-)workﬂow descrip-

tion. On the other hand, a TaskModiﬁcation task sig-

niﬁes a single, low-level workﬂow modiﬁcation at the

task level by pointing to the respective workﬂow part

(i.e., workﬂow task) where this change will be per-

formed. Such a task can be further distinguished into:

• TaskAddition: signiﬁes the addition of a workﬂow

task (represented by an ApplicationTask encapsu-

lating the task description) at the point referenced.

• TaskDeletion: indicates the deletion of the work-

ﬂow task pointed.

• TaskReplacement: signiﬁes the replacement of the

workﬂow task pointed by another also referenced.

A change at the workﬂow level can be permanent or

not. This is signiﬁed by the level attribute in Work-

ﬂowAdaptationTask to cover 3 possible cases: (a)

Class: the change is permanent – case of workﬂow

evolution; (b) InstancePermanent: the change is per-

manent at the current instance but does not affect

the other workﬂow instances; (c) InstanceNonPerma-

nent: this is a special case of an instance-level change

where a task instance in a workﬂow loop is adapted

just once in the context of the current loop repetition.

Finally, cross-cutting adaptation tasks include

level-independent tasks or tasks realised in different

or across levels. These can be further separated into:

• EventCreation: maps to creating an event that can

be consumed by the adaptation system and pos-

sibly lead to an adaptation rule triggering. This

is a nice mechanism enabling to, e.g., deal with

the uncertainty in executing an adaptation rule.

As such, it could check whether its execution was

successful; in the opposite case, it could create an

event to signify that. This can enable formulat-

ing more advanced adaptation rules, accounting

the possibility of adaptation-related exceptions.

• Reporting: in some cases, it could be possible that

the an adaptation rule triggering signiﬁes the oc-

currence of a critical event of which a respective

user, like an admin, should become aware. This

could be useful, e.g., when the admin could com-

plete the partial addressing of the current problem

by the adaptation rule.

• Scaling: scaling is an adaptation task that can be

alternatively performed in different levels (IaaS or

PaaS). Its speciﬁcation is already covered in the

original CAMEL version.

• Migration: a component can be migrated into a

different VM or environment of the same or dif-

ferent cloud provider. As such, this task is speci-

ﬁed by referring to one or more components that

need to be migrated from a certain hosting compo-

nent to another one. The hosting components can

be certain PaaSes or IaaSes, such that we could

have different possible migration cases (e.g., from

PaaS to IaaS or IaaS to PaaS). It can also be indi-

cated whether all instances of the component(s) to

be adapted must be migrated or only the affected

CLOSER 2019 - 9th International Conference on Cloud Computing and Services Science

304

one. The former could be possible when the cur-

rent hosting could be deemed problematic for all

the component(s) instances and not a single one.

4 EXECUTION META-MODEL

4.1 Background

CAMEL’s execution meta-model covers the mod-

elling of historical information related to the execu-

tion of a multi-cloud application. It partitions this in-

formation into groups called ExecutionContexts, rep-

resenting deployment episodes for a certain applica-

tion. An ExecutionModel is then just a collection of

deployment episodes over time for this application.

Covering historical information can be quite im-

portant. First, it can be used to check an application’s

performance capabilities. Second, it can be used to

reason over the best deployments of an application

or its components. Such a reasoning could enable

to accelerate the deployment reasoning time (Kritikos

et al., 2016) as certain application component-to-offer

mappings can be ﬁxed. Third, it can be utilised by,

e.g., a Reinforcement Learning deployment reasoning

algorithm (Horn, 2013) to avoid inspecting deploy-

ments that failed in the past (either leading to errors

or SLO violations). Fourth, it can be used for trace-

ability analysis to check which requirements have led

to producing which application deployment models.

In this respect, CAMEL was designed to cover all

necessary information to support deriving all above

knowledge types. First, the execution context encap-

sulates information related to: (a) what was the appli-

cation’s execution period; (b) the overall cost for it;

drove application deployment and provisioning. Sec-

ond, this execution context was used as a reference

to all other history-related elements that can be mod-

elled. These elements are now shortly explained.

Measurements of speciﬁc MetricInstances are

covered by specifying their value and a reference to

their generation timepoint. They can be also associ-

ated with SLOs to be assessed based on them. De-

pending on the type of the object being measured, we

can distinguish between application, internal compo-

nent, VM, PaaS and communication measurements.

An SLOAssessment covers an SLO assessment’s

outcome and the time point it was performed. SLO

assessments enable to track over time which SLOs

were violated, thus triggering the affected applica-

tion’s global or local reconﬁguration.

Finally, a RuleTrigger represents a scalability

rule’s triggering, also associated with its occurrence

time plus the respective instances of events causing it.

4.2 CAMEL Modiﬁcations

While CAMEL covered well execution history mod-

elling, it still lacked the complete capturing of adapta-

tion information.As such, we have decided to extend

CAMEL to fully cover both adaptation rule trigger-

ing as well as measurability and successability aspects

related to it. The main goal is to allow the adapta-

tion system to assess the suitability of adaptation rules

within an adaptation strategy and dynamically modify

their priority according to the information recorded.

To this end, CAMEL’s execution meta-model (see

Fig. 4) was extended based on the following (3) ways.

First, the RuleTriggering concept was extended to

cover the triggering of adaptation rules as well as the

realisation of adaptation tasks that took place in this

triggering. This gave rise to modelling a new concept.

This concept is named TaskRealisation, covering

details about how an adaptation task was realised in

the context of an adaptation rule. Such details in-

clude when the task execution started and ended, to

compute the task’s execution time, and the execution

result. The latter maps to the next AdaptationResult

enumeration members:

• SUCCESSFUL: the adaptation task did achieve its

main adaptation goal

• UNSUCCESSFUL: the task, while successfully

executed, failed to achieved its adaptation goal

• FAILED: a certain error or failure occurred during

the execution of the adaptation task.

• UNAVAILABLE: the adaptation task was not avail-

able or accessible at the time point of its execution

The ﬁrst two members enable assessing an adaptation

task’s successability, which could be, e.g., measured

by the percentage of times the task attained its goal.

The third member enables assessing the task reliabil-

ity, which could be measured by subtracting from one

the percentage of times task execution has failed. Fi-

nally, the last member enables assessing task avail-

ability, which could be computed by subtracting from

one the percentage of time this task was unavailable.

Apart from this information, a task’s realisation

refers to its parent’s realisation. This could be handy

for traceability reasons, i.e., check how many times

one or more sub-tasks can be blamed for the failure

of a parent task. This could enable discovering those

parent adaptation tasks doomed to fail to address a

“problematic” event due to the “bad” combination of

included sub-tasks. For instance, the task combina-

tion is either overlapping or wrong which could al-

ways lead to the parent task’s unsuccessfulness.

Towards the Modelling of Adaptation Rules and Histories for Multi-Cloud Applications

305

AdaptationResult

UNAVAILABLE

FAILED

UNSUCCESSFUL

ApplicationMeasurement

CommunicationMeasurement

ExecutionContext

SUCCESSFUL

name : EString

totalCost : EDouble = 0.0

endTime : EDate

startTime : EDate

InternalComponentMeasurement

Measurement

name : EString

value : EDouble = 0.0

rawData : EString

measurementTime : EDate

PaaSMeasurement

RuleTrigger

name : EString

trigerringTime : EDate

SLOAssessment

name : EString

assessment : EBoolean = false

assessmentTime : EDate

TaskMeasurement

TaskRealisation

name : EString

adaptationResult : AdaptationResult

endDate : EDate

startTime : EDate

VMMeasurement

AdaptationTask

InternalComponentInstance

PaaSInstance

registryId : EString

VMInstance

ip : EString

Application

name : EString

version : EString

description : EString

DeploymentModel

RequirementGroup

requirementOperator : RequirementOperatorType = AND

Event

name : EString

[1..1] executionContext

[1..*] taskRealisations

[1..1] executionContext

[1..1] measurement

[0..1] parentRealisation

[1..1] adaptationTask

[1..1] task

[1..1] sourceVMInstance

[1..1] destinationVMInstance

[1..1] internalComponentInstance

[1..1] paasInstance

[1..1] vmInstance

[1..1] application

[1..1] deploymentModel

[1..1] requirementGroup

[0..*] deploymentModels

[0..*] internalComponentInstances

[0..*] vmInstances

[0..*] paasInstances

[1..1] event

[0..1] subEvent

Figure 4: The extended execution meta-model in CAMEL.

From the raw information of task realisations, we

can then deduce quality measurements for adaptation

tasks, covering metrics associated with the task exe-

cution time, availability, reliability and successability.

This could provide sufﬁcient support for evaluating

the adaptation rules’ priority and thus their selection

in the context of an adaptation strategy. For instance,

this could be possible by aggregating such measure-

ments and then applying an overall mathematical for-

mula over them to calculate the adaptation rule prior-

ity. Thus, our vision for evolving a multi-cloud appli-

cation’s adaptation behaviour could be easily realised.

The adaptation task measurements also refer to the

event being coped with. This ensures that a correct

aggregation over them can be performed in the con-

text of an adaptation strategy. Further, in case this

is possible (i.e., we know how sub-events of event

patterns map to adaptation sub-tasks), we could also

record the sub-event of the overall event pattern which

the respective adaptation sub-task is supposed to con-

front. This will supply an additional insight of, e.g., a

certain task’s successability across the multiple adap-

tation strategies in which it is potentially re-used.

5 RUNNING EXAMPLE

To demonstrate the two main paper contributions, we

rely on a city trafﬁc management use case relying on

a sequential workﬂow repeatedly executed over time.

This workﬂow comprises the following tasks:

• monitor: monitors a certain city area with respect

to trafﬁc and environment conditions and draws

information concerning special events (e.g., con-

certs) that could take place in the city

• analyse: analyses the current situation, as sensed

Figure 5: The architecture of the use-case system.

by monitor, and produces a trafﬁc regulation plan

• execute: executes the regulation plan derived (by,

e.g., controlling the trafﬁc lights frequency in a

problematic sub-area).

By following a micro-service architecture, these (3)

tasks are mapped to micro-services, which are called

as S

, S

for short, respectively. The ﬁrst service is

deployed in VM V M

, which also hosts an underly-

ing time series data base (TSDB), for storing this ser-

vice’s measurements. The second service is deployed

in VM V M

, including also a NoSQL database for

storing important knowledge required for trafﬁc anal-

ysis. Finally, the last service is deployed in VM V M

All VMs have a different size (e.g., V M

is compu-

tationally and storage-wise wider than the other two)

and were deployed in the city’s private cloud. The

overall system architecture is depicted in Figure 5.

Focusing on S

that realises the analysis function-

ality, the next (2) adaptation rules were modelled:

down(S

) −→ restart(S

) (1)

down(S

) −→ recon f igure(S

) (2)

CLOSER 2019 - 9th International Conference on Cloud Computing and Services Science

306

Table 1: Instance information for TaskRealisation class.

name startTime endTime result task

TR1 1545991912 1545991972 SUCCESSFUL T1

TR2 1545995572 1545995632 UNSUCCESSFUL T1

TR3 1545999232 1545999292 UNSUCCESSFUL T1

TR4 1546002892 1546002952 UNSUCCESSFUL T1

TR5 1546003012 1546003252 SUCCESSFUL CT1

TR6 1546006852 1546007152 SUCCESSFUL CT1

The ﬁrst rule is required to overcome transient by

restarting S

. On the other hand, the second rule can

be employed to overcome permanent errors by rede-

ploying the component on the same VM. Via this re-

conﬁguration, it might be possible that such errors are

corrected by a new version of the respective code.

Both rules address the same event, so the ﬁrst rule

was initially selected as it has a better execution time

than the second. However, such a rule was not al-

ways successful as Table 1 (indicating instances of

the TaskRealisation class) highlights. As such, as that

rule’s successibility rate is below a certain threshold,

the expert decides to replace it with the second rule.

The outcome (depicted in the same table) is satisfac-

tory as the second rule’s successibility rate is 1. Thus,

the adaptation history of the use case workﬂow guides

the expert in making the right choices to modify the

workﬂow’s adaptation behaviour accordingly.

6 CONCLUSIONS

This paper has introduced two extensions to the

CAMEL state-of-the-art cloud modelling language.

The ﬁrst extension concerns CAMEL’s scalability

sub-DSL, enhanced to specify sophisticated adapta-

tion rules as a mapping between events (patterns) to

adaptation workﬂows. Such workﬂows are speci-

ﬁed in a language-independent manner, enabling their

transformation into any workﬂow language, depend-

ing on the workﬂow engine used to execute them.

The second extension concerns CAMEL’s execu-

tion sub-DSL, enhanced via the capability to record

the adaptation history of a multi-cloud application,

including details about the adaptation actions per-

formed, like their start and end time and their out-

come. Such information can be exploited to derive

important knowledge about adaptation actions like

their performance and successibility in terms of ad-

dressing a certain event. This can enable replacing

adaptation workﬂows with alternative ones to better

address the same “problematic” event.

Both extensions provide support to the three main

features of our envisioned multi-cloud application

adaptation framework. The ﬁrst extension enables

supporting any workﬂow execution engine that could

be injected into our adaptation framework, while the

second evolving the adaptive behaviour of a multi-

cloud application which will be evident when the ap-

plication context permanently changes. The appropri-

ateness of the two extensions was demonstrated via

the use of a certain use case.

ACKNOWLEDGEMENTS

The research leading to this survey paper has received

funding from the European Union’s Horizon 2020 re-

search and innovation programme under Grant Agree-

ment No. 731664.

REFERENCES

Erbel, J. M., Korte, F., and Grabowski, J. (2018). Com-

parison and Runtime Adaptation of Cloud Application

Topologies based on OCCI. In CLOSER.

Horn, G. (2013). A vision for a stochastic reasoner for au-

tonomic cloud deployment. In NordiCloud, pages 46–

53. ACM.

Kritikos, K., Magoutis, K., and Plexousakis, D. (2016). To-

wards Knowledge-Based Assisted IaaS Selection. In

CloudCom, pages 431–439. IEEE Computer Society.

Kritikos, K., Zeginis, C., Griesinger, F., Seybold, D., and

Domaschka, J. (2017). A Cross-Layer BPaaS Adap-

tation Framework. In FiCloud 2017, pages 241–248,

Prague, Czech Republic. IEEE Computer Society.

Lushpenko, M., Ferry, N., Song, H., Chauvel, F., and Sol-

berg, A. (2015). Using adaptation plans to control the

behavior of models@runtime. volume 1474, pages

11–20.

Marquezan, C. C., Wessling, F., Metzger, A., Pohl, K.,

Woods, C., and Wallbom, K. (2014). Towards exploit-

ing the full adaptation potential of cloud applications.

In PESOS.

Rossini, A., Kritikos, K., Nikolov, N., Domaschka, J.,

Griesinger, F., Seybold, D., and Romero, D. (2015).

D2.1.3 —- CAMEL Documentation.

Song, H., Raj, A., Hajebi, S., Clarke, A., and Clarke,

S. (2013). Model-based cross-layer monitoring and

adaptation of multilayer systems. SCIENCE CHINA

Information Sciences, 56(8):1–15.

Zeginis, C., Kritikos, K., and Plexousakis, D. (2015). Event

pattern discovery in multi-cloud service-based appli-

cations. IJSSOE, 5(4):78–103.

Towards the Modelling of Adaptation Rules and Histories for Multi-Cloud Applications

307