Experimental Analysis on Autonomic Strategies for Cloud Elasticity

Simon Dupont, Jonathan Lejeune, Frederico Alvares and Thomas LedouxASCOLA Research Group, Mines-Nantes, INRIA-LINA, Nantes, France.

Email: Firstname.Lastname@mines-nantes.frSimon Dupont is also with SIGMA Informatique, Nantes, France.

Abstract—In spite of the indubitable advantages ofelasticity in Cloud infrastructures, some technical andconceptual limitations are still to be considered. For in-stance, resource start up time is generally too long to reactto unexpected workload spikes. Also, the billing cycles’granularity of existing pricing models may incur consumersto suffer from partial usage waste. We advocate that thesoftware layer can take part in the elasticity process asthe overhead of software reconfigurations can be usuallyconsidered negligible if compared to infrastructure one.Thanks to this extra level of elasticity, we are able to definecloud reconfigurations that enact elasticity in both softwareand infrastructure layers so as to meet demand changeswhile tackling those limitations. This paper presents anautonomic approach to manage cloud elasticity in a cross-layered manner. First, we enhance cloud elasticity with thesoftware elasticity model. Then, we describe how our au-tonomic cloud elasticity model relies on dynamic selectionof elasticity tactics. We present an experimental analysis ofa sub-set of those elasticity tactics under different scenariosin order to provide insights on strategies that could drivethe autonomic selection of the proper tactics to be applied.

Keywords-Cloud Computing; Elasticity; AutonomicComputing; SLA; QoS

I. Introduction

According to [1], Cloud Elasticity is defined as thedegree to which a system is able to adapt to workloadchanges by provisioning and de-provisioning resources inan autonomic manner, such that at each point in time theavailable resources match the current demand as closelyas possible. For example, Software-as-a-Service (SaaS)providers relying on Infrastructure-as-a-Service (IaaS)have the capability to quickly cope with highly andunpredictable demands by finely allocating resourcesaccordingly and therefore meeting Service Level Agree-ments (SLAs) previously established with their cus-tomers.In such dynamic environments, human interven-

tion is becoming more and more difficult or evenimpossible. The management of complex architecturesalong with the integration and calibration of all theparameters and constraints that come with to keep thesystem running in an optimized way (e.g., in termsof QoS and cost), is a very complex and error-pronetask. Moreover, human intervention may be too slowto react to some situations such as network, hardwareor software failure or sudden workload oscillation.For those reasons, Autonomic Computing [2] has beenlargely adopted to manage elasticity of cloud services.

Currently, Autonomic Cloud Elasticity is mainlyused to scale the infrastructure resources in the IaaSlayer. Nevertheless, although the recent advances inallowing rapid resource provisioning [3], infrastructureelasticity has faced technical and conceptual limitationsthat prevent infrastructure services to be fully andrapidly elastic. First, resources are limited, which meansthat resources cannot be scaled up infinitely and therecould be times where provisioned resources wouldbe insufficient for infrastructure services’ customers tocope with increasing demands. Second, infrastructureresources initiation time may be too long (ranging fromfew seconds to several minutes [4]) and hence not veryreactive. Third, customers are usually charged for usingresources and, depending on the adopted resourcepricing model, they may suffer of phenomenon knownas partial usage waste [5], in which they are chargedfor more than what they actually consume. Last butnot least, despite of the recent efforts in conceivingand managing datacenters in a more energy-efficientmanner, the energy consumption due to Cloud infras-tructures still remains an issue [6].We advocate that the software at the SaaS layer

can take part in the elasticity process and overcomeinfrastructure elasticity limitations. The reason for thisresides in the fact that the overhead of software recon-figurations can usually be considered as negligible, ifcompared to those of infrastructure services in lowerlayers. Hence, software services have a tremendouspotential to be dynamic and elastic so as to fit incontexts where only the infrastructure elasticity is notenough. Concretely, Software Elasticity can act as anextra elasticity capability that goes beyond the infras-tructure elasticity when resources are scarce. For exam-ple, one can easily and dynamically replace resource-consuming software components by less resource-consuming ones. In the same sense, those less resource-consuming software components can also be used asan alternative to absorb peaks of workload instead ofeither adding infrastructure resources and releasing itstraight away; or getting the resource way too late dueto long initiation times.This paper presents an autonomic approach to man-

age cloud elasticity in a cross-layered manner. Firstof all, we propose a model for software elasticitywhich draws inspiration from the two-dimensionalinfrastructure elasticity, that is, the elasticity based onvertical and horizontal scaling. That results in four di-

2015 International Conference on Cloud and Autonomic Computing

/15 $31.00 © 2015 IEEE

DOI 10.1109/ICCAC.2015.22

81

mensions of elasticity, say, software/infrastructure/ver-tical/horizontal, which provides Cloud providers withmore options that can be used to face the previouslymentioned elasticity limitations. In order to manageall those dimensions in a proper manner, we proposethe orchestration of both elasticities by composingbasic elasticity actions in a synchronous way, usingparallel and sequence operators. From that composi-tion, the Cloud Administrator may derive a numberof extra composed actions that can applied upon dif-ferent events reflecting the need for Cloud resourcereconfiguration. We present an experimental analysison the use of a sub-set of those elasticity tactics (i.e.,event-action pairs) under different scenarios in orderto provide insights on the criteria and the preferenceson them that could drive the autonomic selection ofthe proper tactics to be applied. Those experimentswere conducted on OpenStack, an open-source CloudInfrastructure Manager, which has been deployed atGrid’5000, a French national wide grid for experimentalinfrastructure testbed.The rest of the paper is organized as follows. Sec-

tion II discusses with more details the limitations ofinfrastructure elasticity. Section III presents the conceptof software elasticity and advantages as infrastructurecomplementarity. Section IV presents our proposal ofautonomic approach based on cross-layered elasticitytactics, whereas Section V presents the analysis on theperformed experiments. Sections VI and VII reviewsthe related work and concludes this paper.

II. Infrastructure ElasticityIn this section, we recall some basic definitions be-

fore emphasizing the limitations of the infrastructureelasticity model.

A. DefinitionsInfrastructure Elasticity (IaaS layer): Infrastructure

Elasticity is the ability to rapidly scale infrastructureresources on demand. Figure 1 illustrates the currentinfrastructure resources elasticity model which can beachieved by horizontal or vertical scaling:

• Infrastructure Horizontal Scaling (HSin f ra): ad-justs the VM’s pool size by adding (scale out a.k.a.SOin f ra) or removing (scale in a.k.a. SIin f ra) VMinstances.

• Infrastructure Vertical Scaling (VSin f ra): resizesexisting VM instances by increasing (scale up a.k.a.SUin f ra) or decreasing (scale down a.k.a. SDin f ra)resources allocated (e.g., CPU or RAM). This isusually done by switching from an instance offer-ing to another (e.g., O f fvm(small) to O f fvm(large)in the case of SUin f ra).

B. Limitations1) Resources are limited: For the consumer, the pro-

visioning often appears to be unlimited and availableto be requested in any quantity at any time. How-ever, in reality, there are several limitations in this

Figure 1. Infrastructure Elasticity: Horizontal and Vertical Scaling

(a) (b)Figure 2. Resources Elasticity limitations

regard: (i) IaaS providers usually restrict the numberof infrastructure resource instances (e.g., VMs) to beallocated for each user in order to better managetheir datacenters, but also due to the limitations ofphysical resources (e.g., physical machines or energy).For example, 20 instances (VMs) per zone is the per-user maximum allowed for Amazon EC2 services; (ii)in case of failure (e.g., network), resource availabilitydecreases; (iii) the consumer may find her/himself con-strained with respect to the amount of resources to beused due to a predefined budget or design constraints.Therefore, IaaS resources cannot be provisioned in-

finitely and the maximum resource utilization can bequickly reached, whether it is imposed by infrastruc-ture providers (e.g., small private Cloud infrastruc-tures), by consumers’ restrictions (e.g., budget con-straint) or by the hardware in the case of VSin f ra(e.g., maximum RAM reached). The consequences ofthese limitations on the customers’ applications can beharmful, as illustrated in Figure 2(a). When resourcesbecome saturated (orange line) and the demand in-creases (blue line), it is straightforward that QoS ofdemanding SaaS applications such as response timeand availability are compromised, which may resultin end-users dissatisfaction, financial penalties due toSLA violations (red line) and so forth.

2) Resource initiation time is significant: Although theresource elasticity capability, which enables resourceprovisioning to cope with dynamic environments (e.g.,whose workloads varies within the same day or hour),the non-negligible resource initiation time may be waytoo long and hence prevent just-in-time provisioning.For example, although the recent improvements invirtualized systems, the initiation time of a VM may

82

vary from few seconds to several minutes dependingon several factors like the hypervisor, operating system,memory size, network configurations, among others. Ingeneral, the larger the VM (in terms of memory) moretime is needed to configure, deploy and launch it [4].In this context, it might be completely useless havingthe required resource too long later if the concernedapplication needs to react immediately to cope with achange.Figure 2(b) illustrates an example of such a limita-

tion. In order to absorb a couple-of-minutes workloadpeak, the SaaS provider requests some resources (e.g.,VMs). It turns out that, due to the initiation time, therequested resources are ready to be used only fewminutes later, when the workload is decreasing. To sumup, the infrastructure resource provisioning was notreactive enough to cope with the change (workloadincrease) and thus compromising the software services’QoS and SLA fulfilment. Furthermore, by the momentresources were made available, they were for no use.Consequences can be even worse in cases of oscillatingscenarios as it may suffer of ”ping-pong effect” in therequest/release of resources [7].In theory, VSin f ra allows to tackle this responsiveness

limitation by almost instantly increasing (or decreas-ing) resources of existing instances, as long as themaximum hardware capacity is respected. However,in practice, runtime VSin f ra (without service interrup-tion) is rarely implemented as it imposes a numberof technical constraints in terms of compatibility ofthe infrastructure software stack (operating systems,hypervisor, Cloud management tool) [8]. That is to saythat, most of the times, VSin f ra imposes a service down-time of existing instances while their capacity (O f fvm)are being increased (or decreased). For these reasons,Infrastructure Elasticity is mostly implemented usingthe horizontal scaling, as it is easier to implement.

3) Pricing is per instance-hour: Pay as You Go is autility computing billing model. The time granularityof IaaS resource reservation and the implied resourcebilling model (e.g., hourly, daily, etc.) may also leadSaaS providers to either pay more than they actuallyconsume (e.g., when it requests resource during aworkload peak and releases it right after) or to take intoconsideration the reservation duration before decidingto request more resource. Figure 2(b) also illustratesthe issues related to the billing time granularity. Whena resource allocation becomes useless (e.g., when theworkload starts decreasing), SaaS providers can justrelease the resource. In this case, they will suffer froma phenomenon called partial usage waste [5] in whichthey will pay the entire billing cycle even if the usageduration is inferior to the cycle.Alternatively, in the hope that this resource will be

of any help during the billing cycle, SaaS providersmay employ a use-as-you-pay policy [9], in which, theresource will be kept until the end of the associatedbilling cycle (with a negative impact on energy con-sumption). In any case, regardless the usage policy,

consumers are likely to pay more than what theyactually consume.

III. Enhance cloud elasticity with softwareelasticity

In order to respond to the limitations of the currentCloud elasticity model, we advocate that the softwareat the SaaS layer can take part in the elasticity process.First, we define some software elasticity concepts, thenwe emphasize the synergy between SaaS and IaaSelasticities and we give an illustration.

A. Software ElasticityWe propose a definition of software elasticity and

present the underlying concepts by establishing ananalogy with infrastructure elasticity.

Software Elasticity is the capability of a softwareto adapt itself (ideally in an autonomic manner) tomeet demand changes and/or infrastructure resourceslimitations. By analogy with the infrastructure elastic-ity where IaaS resources (e.g., VMs) are dynamicallyadjusted to fulfil SLA contracts, Software Elasticity pro-vides means for adjusting SaaS resources (e.g., softwarecomponents) in a seamless and instantaneous way tobetter achieve SLA expectations. As the same principleof infrastructure elasticity we distinguish horizontaland vertical scaling :

• Software Horizontal Scaling (HSso f t): in the sameway as for the HSin f ra, HSso f t can be achieved onthe SaaS layer. Then, we introduce SOso f t and SIso f t,that respectively refers to add (scale out) or remove(scale in) software components on the fly.

• Software Vertical Scaling (VSso f t): we draw in-spiration from Infrastructure Vertical Scaling toextend the Software elasticity capability by addingan extra scalability dimension called VSso f t thatrefers to change the offering of existing compo-nent. In this case, the different O f fcomp correspondto variegate the functionalities or non-functionalaspects (e.g., security or logging). Then, we intro-duce SUso f t and SDso f t, that respectively refers toscale up or scale down functionalities and/or non-functionalities to the existing component.

B. Benefits of IaaS and SaaS elasticities complementarityThere are three main benefits in resulting from this

synergy.Alleviate the use of infrastructure resources: re-

sources cannot be scaled up infinitely and the max-imum resource utilization can be attained. Changingthe software offering at runtime (e.g., SDso f t) may helprelieving the resources (e.g., CPU, RAM, etc.) andmay allow to absorb few-minutes workload peaks. Asa consequence the starting of new resources in theinfrastructure layer can be avoided, which could belong and costly [4].

Improve responsiveness of scaling: in order to dealwith highly dynamic environment (e.g., network fluc-tuations, unpredictable workload), the system must be

83

modular and flexible enough but also provide rapidreconfiguration capabilities. The later requirement iscompromised due to non-negligible resource initia-tion times, which may take several minutes. Softwareelasticity, on the other hand, can be more reactive,since, in general, it involves lightweight componentswhose deployment and initiation take less time thaninfrastructure resource ones.

Improve expression capability of elasticity: Table Isummarizes the four scaling dimensions previouslyoutlined along with the eight underlying APIs. In thiscontext, Cloud administrator can create more sophis-ticated reconfiguration plans by orchestrating actionsof different dimensions and then manage finely andeffectively his/her cloud resources.

C. Illustrative Example

In order to illustrate the concept of Software Elastic-ity, and more specifically the new VSso f t dimension, wegive an example which consists of a SaaS applicationfrom the domain of internet advertisement. The appli-cation behaves in an autonomous manner by choosingthe appropriate O f fcomp for the advertising componentin accordance with the current workload, the runtimecontext and some constraints on the advertisementquality, the performance and the energy compliance. Inthis example, the advertising component provides fourdifferent offerings which are Video HD, Video, Imageor Text. The Video HD and Video offerings provide abetter Quality of Experience (QoE) to end-users thanImage or Text ones but more computation time tooperate the service.

(a) step 1: all SLO are met (b) step 2: workload increase

(c) step 3: infrastructure scaling (d) step 3’: software scalingFigure 3. Impact of HSin f ra and VSso f t on the response time

Figure 3 shows the impact of HSin f ra and VSso f ton the response time metric. We voluntarily fixed thevalue of the dimensions HSso f t and VSin f ra for a betterunderstanding. We can see HSin f ra, with the amountof resources (e.g., number of VMs), on the horizontalaxis and response time expectations on the vertical axisfor a specific workload and request type. The blue axisrepresents the VSso f t with the different O f fcomp for theadvertising component.We consider a SLA established between the end-

users and the SaaS provider. This SLA contains twoService Level Objectives (SLO) which describe a com-mitment to maintain a particular state of the servicein a given period. The first one corresponds to aSLO Response Time indicating that the service mustrespond under 1200 ms (purple area). The second oneformally specifies the O f fcomp usage expected by theend-user and guaranteed by the SaaS provider. In ourexample, it is stated that the advertising componentcannot be provided with the O f fcomp Text (green area).We can imagine SLOs specifying the percentage ofutilization of each O f fcomp (e.g., 75% Video HD, 20%Video, 5% Image) for a certain time window (e.g., 1day).In Figure 3(a), we consider a given workload and

an initial application configuration (infra: 2 VMs ; soft:O f fcomp HD) which meets all SLOs. Let’s consider, in asecond step (see Figure 3(b)), an increasing workloadwhich leads to a response time SLO violation with theactual configuration. In order to retrieve a suitable con-figuration (i.e., respecting the SLOs), it becomes neces-sary to reconfigure the application to absorb the newdemand. If we consider each dimension independentlyfor simplicity, there are two possible reconfigurations:

• (i) increase the number of VMs by executing aSOin f ra and then balance the load on more workers(see Figure 3(c));

• (ii) change the O f fcomp by executing a SDso f t andthen reduce the request computation time (seeFigure 3(d)). In this context, it should be noted thatthe execution of SDso f t must be done in accordancewith the SLO in terms of O f fcomp usage.

In this simple example, we have considered onlytwo scaling dimensions instead of the four usable.Moreover, the suggested reconfigurations involve onlyone or the other dimension. As we will see later, it ispossible to make use of different scaling dimensionswithin the same reconfiguration plan and then benefitfrom their joint use.

IV. Elasticity Strategies for Autonomic CloudServices

In this section, we describe our autonomic cloudelasticity model which relies on dynamic selection ofelasticity strategies.

A. PaaS Autoscaling ServiceOur autonomic cloud elasticity model can be likened

to PaaS which aims to manage the elasticity of re-

84

Table ICloud Elasticity Scaling actions

Scaling Dimension API Name Description

Infrastructure Horizontal Scaling (HSin f ra)Scale Out Infrastructure (SOin f ra) Add VM(s) to the poolScale In Infrastructure (SIin f ra) Remove VM(s) from the pool

Infrastructure Vertical Scaling (VSin f ra)Scale Up Infrastructure (SUin f ra) Increase offering (O f fvm) of existing VM(s)Scale Down Infrastructure (SDin f ra) Decrease offering (O f fvm) of existing VM(s)

Software Horizontal Scaling (HSso f t)Scale Out Software (SOso f t) Add software component(s) to the applicationScale In Software (SIso f t) Remove software component(s) to the application

Software Vertical Scaling (VSso f t)Scale Up Software (SUso f t) Increase offering (O f fcomp) of existing component(s)Scale Down Software (SDso f t) Decrease offering (O f fcomp) of existing component(s)

sources (e.g., software component, virtual machines,physical infrastructure). This kind of service is usuallycalled autoscaling service. In the rest of this section, wecall Cloud Administrator (CA for short) the person incharge of the management of the autoscaling service. Inorder to manage the Cloud system, CA needs a wayto monitor and act on both IaaS and SaaS resources.These resources must provide the necessary interfaces,that is to say, the APIs enabling the PaaS AutoscalingService to interact with them.

B. Autonomic Cloud Elasticity Model overview

The autonomous management of our model resultsin an implementation of the MAPE-K loop referencemodel [2], as shown in Figure 4.

Figure 4. Cloud Resources Model Overview

The MAPE-K loop is applied to a cloud resourcesgraph. The autonomic manager, that is to say the MAPE-K loop, interacts with the managed system through twointerfaces that are the sensors and actuators to superviseand act on the system respectively.The loop is fed by the sensors following a push

mode which means that the managed system (i.e. cloudresources) pushes metrics to the M of the autonomicmanager. Based on the received data, M uses Com-plex Event Processing (CEP [10]) to aggregate metricsand generate complex high level events which denotepertinent information about the health status of themanaged system requiring reconfiguration decision.Events are triggered by M and send to decision part

of the loop for analyse. The decision, which corre-sponds to A and P phases in our work, comprisesthree steps in the form of consecutive filters that wewill detail later in this section. The decision part willoutput a reconfiguration plan which to be applied onthe managed system by the E phase through actuatorcalls and then meet the problem represented by theincoming event.The K comprises data shared among all MAPE

phases such as current cloud resources graph withassociated metrics values, runtime constraints and pref-erences expressed on the system. It also contains pre-defined symptoms and reconfiguration plans in theform of event patterns and predefined actions respectively.Last but not least, K includes a mapping betweenpredefined events and actions that results in a cata-logue of event-action pair called tactics. As we shallsee later, decision part aims to filter these tactics byconfronting them to monitoring, runtime constraintsand preferences expressed by the Cloud Administrator.

C. Resources Model: managed systemWe focus on n-tier web applications and we model

a resource hierarchy as follows: each tier of the appli-cation is composed of virtual machines (VM for short)accommodating software components. VMs are hostedon an infrastructure corresponding to a set of physicalmachines (PM for short).Figure 5 illustrates a simple cloud resources model

instance (i.e. managed system) which is a 2-tiers appli-cation deployed on a 2 PMs’ infrastructure. Each tierconsists of VMs hosted on PM (dash lines). Each VMcontains the software components associated with itstier. Thus, one can see an instance of the model as aresource graph composed of two sub-trees. The left onerepresents the physical architecture view of the appli-cation (considering the PM-VM mapping) whereas theright one gives the logical architecture view (with themapping tier-VM).

D. Monitor: eventsIn our model, each cloud resource has a set of metrics

reflecting its state of health. The managed system ex-hibits these metrics through sensors making possible tocapture their values at runtime. The monitor phase cancollect and aggregate multiple sensors values over timein order to make timely relevant information about thesystem health status in the form of event.

85

Figure 5. Instance of cloud resources model (managed system)

We distinguish two kinds of events: Basic Event andComplex Event. Basic Events denote pertinent informa-tion for one metric of one resource. For example, if CPUconsumption of one VM has exceeded a maximumthreshold, generate a HighCPU vm event. ComplexEvents are composite events and may involve one orfew metrics of one or several resources with differenttime scales. We rely on CEP [10] to generate newcomplex events through aggregation and compositionof basic ones. Then, it becomes possible to detect com-plex relationships between events overtime by definingcorrelation rules also known as Event Patterns.CA can take advantage of the tree structure of the

cloud resources model to define its events patternsspecifying hierarchical-based relationships. Then, hecould define a CEP rule that looks at some nodes’states according to the parent node’s state relying onthe father-son relationship as shown in red in Figure5: if the response times observed on a tier exceeds amaximum threshold (HighRT tier on Tier1) and theunderlying VM(s) have excessive CPU consumption(HighCPU vm on VM1). This example shows an eventpattern which could generate new kind of complexevent named HighRT tier Overloaded vms by aggre-gating basic events. The hierarchical structure alsoenables to track the temporal evolution of a symptomwatching the propagation of correlated metrics in thetree overtime as shown in yellow on the same fig-ure: a response time problem began on Tier1 at t1,and then appeared on Tier2 at t2 before impactingthe application itself at t3. This example can also bedesigned as event pattern to generate complex eventscalled HighRT upward. Moreover, hierarchical struc-ture allows to identify trends (upward or downward)or causal relationships between symptoms.Based on his knowledge of the system and the

potential help of test team members who performedscalability tests, CA can define situations or symptomsthat need to pay attention by specifying some EventPatterns at design time. These patterns are stored inthe Knowledge and evaluated at runtime.

E. Execute: predefined actions

Cloud resources are associated with a set of actionsthat can be operated through actuators, offering recon-figuration capability to the system. The set of actuators

exhibited by the system constitutes its reconfigurationAPI.As for events, we distinguish two kinds of actions:

Basic Action and Complex Action. Basic actions resultin a single actuator call. The basic actions consideredin our work have been listed and detailed previouslyin Table I. With software elasticity, it becomes pos-sible to benefit from the advantages of the differentscaling dimensions by using their related actions in asmart and coordinated way. We propose the conceptof Complex Action which denotes an orchestration ofbasic actions constituting an executable self-containedreconfiguration plan.Figure 6 shows an example of complex action using

the BPMN 2.0 formalism. The example meets a needfor additional resources. It involves two scaling dimen-sions from two layers (HSin f ra and VSso f t) through 3different basic actions which are composed in paralleland sequence.The goal of this complex action is to absorb the re-

source initiation time when a SOin f ra is called and there-fore face the reactivity limitation previously mentioned.Concretely, when a need for additional resources occurs(e.g., HighRT tier - step 1), we execute in parallel aSOin f ra (e.g., adding one VM to the pool - step 2) anda SDso f t (e.g., switching the O f fcomp from Video HDto Image - step 2’) to relieve infrastructure resourcesduring the initiation of the VM. We wait for a specificduration (e.g., timer) or until resources are ready (step3), then we execute a SUso f t (e.g., switching back toVideo HD - step 4) to retrieve a nominal state.

Figure 6. Complex action example: (SDso f t || SOin f ra) ; SUso f t

Another example of complex action could be themigrate action allowing migration of stateless VM(s)from a source PM to a target PM. This means execute aSOin f ra on target PM and wait until VM is ready, thenexecute SIin f ra on source PM.As for events patterns, CA is able to provide a set

of predefined scaling actions (basic or complex) atdesign-time relying on its knowledge of the systems(e.g., following calibration tests) and possibly withthe assistance of architects (system or software). Theseactions are stored in the Knowledge and will be appliedat runtime by the MAPE-K loop. We will discuss laterthe manner in which the actions are selected.It should be noted that the number of predefined

symptoms and actions remains reasonable. CA doesnot specify thousands of event patterns or actions. Thisis an iterative and incremental approach in which theCA is able to refine its model by adding/removingsymptoms/actions progressively by relying for exampleon calibration tests or the behaviour of the application

86

at runtime.

F. Reconfiguration DecisionThis section aims to present the decision part of our

autonomic platform. We will detail the three differentsteps, which take the form of filters, making the bridgebetween the M and E phases of the MAPE-K loop.

1) Tactics Filter – Event-Action Mapping: CA is ableto describe situations requiring reconfiguration of thesystem, in the form of event patterns, but also possiblereconfiguration plans that it wants to apply to thesystem, in the form of predefined actions. Besides,he needs to make the link between events patternsand predefined actions. This link is done through theconcept of Tactics, defining a reconfiguration solutionin response to a provisioning issue.A tactic is actually an event-action pair defined by

CA and representing a well-known IF-THEN statement(e.g., if(event) then action). Thereby, the CA is ableto provide the mapping between events and actionswhich corresponds to establish a catalogue of tacticsstored in the Knowledge. These tactics will be automat-ically filtered at runtime depending on the triggeredevents. When an event occurs at runtime, the TacticsFilter takes a look at the event-action mapping storedin the Knowledge, that is to say select eligible tacticspreviously defined as solutions to the problem repre-sented by the incoming event. Figure 7 illustrates theevent-action mapping. We can see a set of predefinedEvents which have been designed in the form of eventpatterns and a set of predefined Actions. Each pair(e, a) ∈ Events × Actions defines a tactic. The tacticscatalogue is the set composed of all (e, a) pairs.

Figure 7. Example of Event-Action Mapping

2) Constraints Filter – Context: The runtime con-text can induce some constraints that may preventto execute eligible tactics. Although the monitoringphase provides a view of the current context withinthe various probes values, the system is also facedwith runtime constraints defined on resources. Theseconstraints can be numerous and various (e.g., budgetconstraint, technical restriction, etc.) and are stored inthe Knowledge to be evaluated at runtime. This is thepurpose of the second filter named Constraints Filterwhich takes as input the eligible tactics (provided bythe first filter) and the run-time constraints in orderto identify unsuitable tactics and thus outputting onlyapplicable tactic(s) (see Figure 4).

An example of constraint could be the maximumcapacity of PM in terms of CPU or RAM. In the sameway, an SLO regarding the use of a O f fcomp can beconsidered as constraint (e.g., O f fcomp Text can not beused from 8:00 p.m. to 11:00 p.m.). Such constraintsmay limit the scope for reconfiguration by preventingto apply certain tactics. For example, in the case ofPM capacity constraint, if the maximum capacity of thePM is reached, adding a new VM (SOin f ra) on it willbe impossible. With regard to the second constraint,the SLO may limit the use of VSso f t dimension. Thisfiltering step may be sufficient to identify the tactic toexecute if only one tactic remains applicable, but if itis not the case, we need a last filtering step.

3) Preferences Filter – Strategy: By specifying theevent-action mapping, Cloud administrator can given possible actions to solve a same problem, which isformalized by n eligible tactics for an event. When anevent occurs at runtime, after applying the first twofilters, it can remain few applicable tactics. Which oneto choose? Are they equivalent? What is the best fromthe provider point of view? And for the customers? Inorder to answer these questions and decide among theremaining tactics, we need a last filter based on CApreferences.Although the execution of these tactics provide an

answer to the problem, they are not equivalent. Indeed,there may be several criteria to take into account, asfollows:

• Cost: the financial impact including the price ofthe infrastructure and licensing;

• QoS: the effects in terms of QoS;• QoE: the impact on VSso f t dimension;• Elasticity Time: the total time required to executethe tactic;

• Responsiveness: the ability of the tactic to reactquickly. It differs from the elasticity time thatconsiders the full execution of the tactic.

The list of criteria is not exhaustive and may bechanged or completed depending on the system, thekind of application, the type of workload, etc. Relyingon its system knowledge and calibration tests, the CAwill give rates on tactics by assigning values to criteriain the form of strategies and stores them in the K.In the next section, we evaluate several tactics by

following the calibration process that could be achievedby the CA. Then, we analyse and discuss the resultsin order to present advantages and disadvantages ofeach tactic depending on workload scenario and run-time context. This approach allows the identification ofcriteria for comparing the predefined tactics and settingpreferences in the form of strategies. The objective ofour experiments is to provide insights on the criteriadriving the autonomic selection of elasticity tactics.

V. Experiments

In this section, we present an experimental study onthe impact of different tactics over a cloud application

87

in terms of reconfiguration actions and performance(e.g. response time and availability). The final goal ofthis is to show how a cloud administrator can definethe strategy filter among a set of tactics.

A. Experimental testbed and configuration1) Application configuration: We consider a cloud ap-

plication developed in a SaaS-fashion. The applicationis architecturally organized in 2-tiers: the first one is theload balancing tier (lbt), whereas the second one is thebusiness tier (bt). For the lbt, we rely on Nginx 1.6.2to distribute workload across our multiple workersof the bt. The second tier consists of Java applicationand a web server Jetty. The software component thatimplements the lbt is equipped with software elasticitycapabilities, meaning that it has several offering levels(O f fcomp). We implement them by gradually increasingthe degree of CPU intensiveness at each level. Finally,each component instance (of the lbt or bt) is deployed ata virtual machine, which is offered by the infrastructureprovider.

2) Infrastructure configuration: The experiments wereconducted on Grid’5000 Nancy, by using 7 physicalmachines linked by a 20 Gbit/s Ethernet switch. Eachmachine has two 2.8GHz Xeon processors (4 cores perCPU) and 15GB of RAM, running Linux 2.6 Machines.The used cloud computing platform is Openstack Griz-zly 1.0.0, which requires one dedicated physical ma-chine, the cloud controller, to manage the system. Con-sequently, 6 physical machines are dedicated to hostvirtual machines, which in turn, are pre-configured torun Ubuntu 12.04.

3) Autonomic Manager: Our autonomic manager pro-cess is hosted on the cloud controller machine. Itmonitors the average response time of received andprocessed requests by aggregating the lbt’s Nginx logsin a given time window (in our case 15 seconds).According to a comparison of this value with twothreshold values, two event patterns can be issued :

• ”High Response Time” occurs when the monitoredvalue is higher than an upper threshold. It reflectsan under-provisioned system leading eventually toa SLA violation;

• ”Low Response Time” occurs when the monitoredvalue is lower than a lower threshold. It reflectsan over-provisioned system leading eventually touseless operating costs.

In response to High Response Time, the autonomicmanager may execute either SOin f ra, so as to increasethe system’s capacity in terms compute resources(VMs); SDso f t, in order to absorb more workload withthe same amount of compute resources; or a parallelcomposition of these two basic actions, composed insequence with SUso f t. Regarding the event Low Re-sponse Time, the autonomic manager may executeeither SIin f ra so as to free allocated compute resourcesor SUso f t to upgrade the QoE by increasing the O f fcomp(see Table II). For sake of simplicity we do not considerthe basic actions associated with the VSin f ra and HSso f t.

Table IIDefinition of tactics used in the experiment

Event Action

High Response TimeSOin f raSDso f t

(SOin f ra || SDso f t); SUso f t

Low Response Time SIin f raSUso f t

B. Experimental evaluation1) Experimental setup: We fixed the upper and lower

threshold firing the High/Low Response Time events to400ms and 20ms, respectively. In the case of the upperthreshold, that corresponds to a threat threshold smallenough to avoid that the response time reaches 1000ms.With respect to the lower one, it is big enough toidentify an over-provisioning case.In our evaluation analysis, we considered three ex-

periments. Each experiment directly applies for eachevent pattern, i.e. High Response Time and Low ResponseTime a unique action (cf. Table II) over the business tier:

• Experiment 1: SOin f ra and SIin f ra, where SOin f ra(resp. SIin f ra) action adds (resp. removes) one vir-tual machine;

• Experiment 2: SUso f t and SDso f t, where SUso f t(resp. SDso f t) action degrades (resp. upgrades) onelevel of O f fcomp for each running component in-stance/virtual machine in the tier;

• Experiment 3: (SOin f ra || SDso f t); SUso f t and SIin f ra,where (SDso f t || SOin f ra); SUso f t is a composite action(see Figure 6) which degrades 4 levels of O f fcompfor each running component instance/virtual ma-chine in the tier and waits until the virtual machineresulting from the SOin f ra starts, then it upgradesback 4 levels of O f fcomp.

Figure 8 shows, through those experiments, the evo-lution of the state and performance of the business tierover the time with a given input workload scenario.A workload value is a number of requests per secondsent to the application. In all sub-figures, this value isrepresented by the black curve of the right y axis. Theconsidered workload scenario lasts 40 minutes and hasthree phases:

• First phase: the workload increases during 10 min-utes with a medium speed-up (0.4 request/sec2)and then decreases during 3 minutes up to thestarting point;

• Second phase: the workload increases during 10minutes with a half speed-up of the first phase (0.2request/sec2) during 10 minutes and then decreasesduring 3 minutes up to the stating point;

• third phase: three peak loads are injected at reg-ular interval characterizing a high speed-up (1.6request/sec2) for a short period of time.

These three phases enable us to evaluate the con-sequences of the different considered tactics over theapplication with different speed-up value.During the experiments, we gather and observed the

following metrics:

88

• Infrastructure’s Size: the number of running vir-tual machines (Figures 8(a), 8(b) and 8(c));

• Software Offering (O f fcomp): the offering of theapplication, which have 5 different values. Thehigher the value, the higher the QoE (Figures 8(d),8(e) and 8(f));

• Number of Failed Requests: the number of re-quests which are not able access to the service inone second (Figures 8(g), 8(h) and 8(i)). This metricshows the unavailability of the application;

• Average Response Time: the average responsetime of processed requests in one second (figures8(j), 8(k) and 8(l))

The initial configuration, that is, the system configu-ration before receiving any request, is one componentinstance (which corresponds to one virtual machine)for each tier and the maximum level of O f fcomp for thecomponent in the bt.Finally, the reconfiguration execution time is repre-

sented by a green area in Figure 8. Since this primitiveis costly in terms of reconfiguration time, it is interest-ing to show the behaviour of the application duringthe action execution.

2) Analysis and discussion: We can notice that Exper-iments 1 and 3 follow the same behaviour in terms ofinfrastructure’s size (Figures 8(a) and 8(c)): the numberof VMs increases whenever a High Response Time eventoccurs during a workload increase. Indeed, as we cansee in Figures 8(j) and 8(l), the action correspondingto this event starts its execution whenever the averageresponse time exceeds the upper threshold. Since Ex-periment 2 is deprived of action SOin f ra, the number ofVMs remains constant (Figure 8(b)) all the time.Experiment 1 keeps the same level of O f fcomp (Figure

8(d)) since the SDso f t action is disabled, contrary toExperiment 3, which decreases the O f fcomp at eachoccurrence of event High Response Time (Figure 8(f)).This difference has an impact over the average responsetime and the unavailability of the application. Indeed,in the first phase of our scenario, there is a huge degra-dation of performance during the reconfiguration exe-cution of Experiment 1 (Figures 8(g) and 8(j)), whereasfor Experiment 3, we remark a full availability and anexcellent average response time (Figures 8(i) and 8(l)).This shows that the parallelization of O f fcomp degra-dation and the SOin f ra allows to absorb the workloadincreasing during the reconfiguration period, whichallows the application to keep a constant full availabil-ity and thus meet the SLAs. However in the secondphase, as can be noticed in Figures 8(g), 8(i), 8(j) and8(l), Experiments 1 and 3 do not induce a worseningof performance. Consequently, in Experiment 3, theO f fcomp has been uselessly degraded. In the third phaseof our scenario, Figures 8(g), 8(i), 8(j) and 8(l) showthat a SOin f ra is inefficient: the performance is degradedduring the peak load in both experiments. Moreover,the long reconfiguration period (VM initiation time)makes the new VM useless since it becomes effectiveonly after the bursts.

Concerning the Experiment 2, Figure 8(e) showsthat the modification of O f fcomp level induces a shortexecution time in comparison with the SOin f ra action.Nevertheless, we can remark an oscillation periodbetween two successive values when the workloadincreases (especially in the phases 1 and 2) implyingthat High Response Time event and Low Response Timeare triggered alternatively. This phenomenon can beexplained thanks to two characteristics of the softwareelasticity:

• High Reactivity: the new configuration is quicklyoperational implying that workload variation dur-ing reconfiguration execution has no impact overperformance

• O f fcomp levels are too coarse grained: the dif-ference of performance between two successiveO f fcomp levels is too large, which makes the au-tonomic manager oscillates. In other words, upona High Response Time, the manager is induced todegrade the level of O f fcomp. At the degraded level,the performance is too high so the lower thresholdis exceeded and a Low Response Time is fired. Thisbehaviour is repeated while the load increases.

Figures 8(h) and 8(k) show that this oscillation iscostly in terms of performance. In the third phase, wecan observe that the performance of Experiment 2 is thesame than the other two: we can notice an unavoidableperiod of unavailability and response time increase dueto the sharp increase of load. However, Experiment2 prevents the overhead of a SOin f ra, i.e., it does notincrease the cost of the infrastructure.According to our autonomic model and the tactics

defined in this evaluation, for the same High ResponseTime event, three actions are possible. This mappingcorresponds to the tactic filter of our autonomic model(cf. Figure 4). Following the filter scheme, in this exam-ple, the three actions would also pass the context filter.This filter could be useful if we had a SLA forbiddingthe degradation of O f fcomp: in this case only the SOin f raaction would be applicable. If still, there are sev-eral possible eligible actions, the autonomic managershould pick one to be performed. Our experimentalanalysis shows that each action has its advantages anddisadvantages depending on the workload as detailedbelow:

• SOin f ra action fosters QoE at the expense of reac-tivity and infrastructure’s cost. It is interesting toapply it in the case of slight workload increasebecause there is no need for the application tobe reactive. Instead, there is a need to continouslyincrease the amout of compute resource (VMs).

• SDso f t action fosters infrastructure’s cost and reac-tivity at the expense of QoE. This action makessense in the case of bursting workload whereadding infrastructure resources may take too longto meet sudden changes.

• (SDso f t || SOin f ra); SUso f t action fosters reactivity atthe expense of infrastructure’s cost and punctually

89

1

2

3

0 min (phase 1)

13 min (phase 2)

26 min (phase 3)

40 min

50

100

150

200

250

300In

fras

truct

ure’

s siz

e (n

umbe

r of v

ms)

Load

(num

ber o

f req

uest

per

sec)

time (min)

(a) Experiment 1: infrastructure’s size

1

2

3

0 min (phase 1)

13 min (phase 2)

26 min (phase 3)

40 min

50

100

150

200

250

300

Infr

astru

ctur

e’s s

ize

(num

ber o

f vm

s)

Load

(num

ber o

f req

uest

per

sec)

time (min)

(b) Experiment 2: infrastructure’s size

1

2

3

0 min (phase 1)

13 min (phase 2)

26 min (phase 3)

40 min

50

100

150

200

250

300

Infr

astru

ctur

e’s s

ize

(num

ber o

f vm

s)

Load

(num

ber o

f req

uest

per

sec)

time (min)

(c) Experiment 3: infrastructure’s size

1

2

3

4

5

0 min (phase 1)

13 min (phase 2)

26 min (phase 3)

40 min

50

100

150

200

250

300

Softw

are

offe

ring

Load

(num

ber o

f req

uest

per

sec)

time (min)

(d) Experiment 1: Software offering

1

2

3

4

5

0 min (phase 1)

13 min (phase 2)

26 min (phase 3)

40 min

50

100

150

200

250

300

Softw

are

offe

ring

Load

(num

ber o

f req

uest

per

sec)

time (min)

(e) Experiment 2: Software offering

1

2

3

4

5

0 min (phase 1)

13 min (phase 2)

26 min (phase 3)

40 min

50

100

150

200

250

300

Softw

are

offe

ring

Load

(num

ber o

f req

uest

per

sec)

time (min)

(f) Experiment 3: Software offering

0

50

100

150

200

0 min (phase 1)

13 min (phase 2)

26 min (phase 3)

40 min

50

100

150

200

250

300

Am

ount

of f

aile

d re

ques

ts

Load

(num

ber o

f req

uest

per

sec)

time (min)

(g) Experiment 1: Amount of failed requests

0

50

100

150

200

0 min (phase 1)

13 min (phase 2)

26 min (phase 3)

40 min

50

100

150

200

250

300

Am

ount

of f

aile

d re

ques

ts

Load

(num

ber o

f req

uest

per

sec)

time (min)

(h) Experiment 2: Amount of failed requests

0

50

100

150

200

0 min (phase 1)

13 min (phase 2)

26 min (phase 3)

40 min

50

100

150

200

250

300

Am

ount

of f

aile

d re

ques

ts

Load

(num

ber o

f req

uest

per

sec)

time (min)

(i) Experiment 3: Amount of failed requests

1

2

3

4

5

6

7

8

0 min (phase 1)

13 min (phase 2)

26 min (phase 3)

40 min

50

100

150

200

250

300

Ave

rage

resp

onse

tim

e (s

)

Load

(num

ber o

f req

uest

per

sec)

time (min)

(j) Experiment 1: Average response time

1

2

3

4

5

6

7

8

0 min (phase 1)

13 min (phase 2)

26 min (phase 3)

40 min

50

100

150

200

250

300

Ave

rage

resp

onse

tim

e (s

)

Load

(num

ber o

f req

uest

per

sec)

time (min)

(k) Experiment 2: Average response time

1

2

3

4

5

6

7

8

0 min (phase 1)

13 min (phase 2)

26 min (phase 3)

40 min

50

100

150

200

250

300

Ave

rage

resp

onse

tim

e (s

)

Load

(num

ber o

f req

uest

per

sec)

time (min)

(l) Experiment 3: Average response timeFigure 8. Experimental results

the QoE. This action should be applied in the caseof a workload that increases moderately becausethere is a need for both reactivity and continuousscaling out of infrastructure resources.

Table III summarizes the three identified criteria:reactivity, QoE and infrastructure’s cost. In this table+ and − mean positive and negative influence oncriteria respectively. The value 0 means both positiveand negative influence. In conclusion, the Cloud Ad-ministrator could define a strategy by specifying itspreferences on the criteria. For instance, (reactivity,

QoE, infrastructure’s cost) for an application whoseworkload is similar to the first phase of our scenario.

Table III(Dis)Advantages of tactics according to criteria

Reactivity QoE Infrast.Cost

SOin f ra − + −SDso f t + − +

(SDso f t‖SOin f ra); SUso f t + 0 −

90

VI. RelatedWork

A. Cloud Elasticity ManagementCloud computing promises to completely revolu-

tionize the way to manage resources. Thanks to in-frastructure elasticity, resources can be provisioningwithin minutes to satisfy a required level of QoSformalized by SLAs between different Cloud actors.This can be achieved in a completely adhoc manner bydynamically adjusting resources according to a set ofpredefined auto-scaling rules. Examples of such a kindof approach are implemented by industrials such asAmazon Auto Scaling, Microsoft Azure Auto-scalingApplication Block, but also in research work [11] [12].However, setting up auto-scaling rules in order to

respect SLAs while minimizing service cost is not atrivial task since many parameters must be taken intoaccount. For this purpose, an effective Capacity Plan-ning may require the combination of several solutionsout of different domains. For example, in order tomodel systems’ performance, Queuing Theory [13] [14]can be applied. Alternatively, Reinforcement Learning[15] [16] and Game Theory [17] [18] might be used re-spectively to give a more effective performance profilesor to deal with economy equilibrium and thus improveresources requirements estimations. Those techniquescan be combined along with operational research tech-niques such as Constraint and Linear Programming inorder to find solutions that respect the constraints (e.g.,imposed by SLAs) or even solution that optimizes aspecific criterion such as QoS or cost.With respect to these works, most of them focus only

on method accuracy and ignore Cloud technical andconceptual limitations. Some initiatives are interestedin solving technical limitations, such as [19] and [20],while conceptual limitations (e.g., economic model) arenot addressed. [21] proposes an approach based on ver-tical scaling to prevent duplicating time for data-basetier. However, the vertical scaling is not provided by allIaaS providers or not as hot scaling, which means theVM needs to be rebooted with potential downtime andsignificant initialization time. [19] presents a predictivemodel to absorb the initialization time. The accuracy ofprediction method depends on the input window sizeand the prediction interval but the authors do not detailthese values. [20] utilizes fuzzy logic to define moreelastic auto-scaling rules but they only focus on qual-itative specification of thresholds. Furthermore, mostof the auto-scaling solutions consider only low-levelperformance metrics (e.g., CPU utilization at IaaS level)which is a good indicator for system utilization infor-mation, but it cannot truly reflect the QoS provided bySaaS application and neither show if application per-formances meet user’s requirements [22]. Finally, mostof the existing works only deal with the infrastructurelayer whereas only infrastructure elasticity may notbe enough to meet technical or conceptual limitations.Our work, instead, advocates that the software layermust take part in the elasticity process to overcome

infrastructure elasticity limitations.

B. Cross-layer Elasticity Management

According to our knowledge, only few studies havefocused on expanding system’s elasticity capability tothe software layer. [23] is interested in architecture-based self-adaptation. They developed Rainbow [24], aframework which is similar to a MAPE-K model [2], us-ing software architectures and a reusable infrastructureto support runtime self-adaptation of software systems.For illustration, they rely on the Znn.com case study(also known as ZAP.com or Z.com), a web-based systemthat serves multimedia news content. The objective isto serve news contents within a reasonable responsetime while keeping the resources’ associated cost undera predefined threshold. In the case of sudden andunanticipated workload increase, to prevent serviceunavailability due to resource elasticity limitations,Znn.com opts to serve minimal textual content insteadof a multimedia one. In others words, the adaptationobjective is to maximize the QoS and minimize theinfrastructure cost by changing the offering of theexisting component. The Znn.com system’s adaptationcapability allows to act both on the infrastructure andthe software layers. Similarly, our work relies on au-tonomic computing but we address more concretelythe domain of Cloud computing. In particular, ourapproach goes further since we propose a catalogueof reconfiguration strategies driven by the Cloud ad-ministrator preferences.Similar to our work, [25] introduces a self-adaptation

programming paradigm, called brownout, allowing ap-plications to robustly face unpredictable runtime vari-ations without over-provisioning. The paradigm isbased on optional code that can be dynamically deac-tivated through decisions based on control theory. Wepropose a broader approach since we rely on a synergybetween infrastructure elasticity and software elasticity.

VII. Conclusion

In this paper, we highlighted the main shortcomingsof the standard Cloud elasticity model. We claimed thatthe software layer (SaaS) can take part in the elasticityprocess, which could be evidenced with the help ofdifferent examples that demonstrate the advantages ofusing infrastructure and software elasticities together,in a coordinated way, to overcome the current limita-tions and improve reconfiguration decisions.First of all, we propose a model for software elasticity

which draws inspiration from the vertical/horizontalinfrastructure elasticity. It results in four dimensionsof elasticity which allow Cloud providers to finely andeffectively manage their cloud resources.Based on a set of experiments performed on a real

infrastructure testbed, we provided an experimentalanalysis and discussion on the use of three elasticitytactics (i.e., event-action pairs) under different scenariosin order to provide insights on criteria and preferences

91

that could drive the autonomic selection of the propertactic(s) to be applied.We are currently working on the design of a Do-

main Specific Language (DSL) for Cloud Elasticity.This language, called Elascript, is a scripting language(with an associated graphical formalism) which offersa way to define complex and safe reconfiguration planssimply and concisely. The expressiveness of DSLs canoffer more guarantees and extensive static analysis thangeneral languages. In this way, Elascript can detectunbearable code sequences that have no meaning for areconfiguration plan (e.g., trying to execute SUso f t andSDso f t on the same component in parallel) and thenhelp the Cloud Administrator in its management task.In the near future, we plan to extend our experi-

ments to numerous tactics involving the four elasticitydimensions mentioned above with more complex ar-chitectures and under various types of workload. Wethus hope to refine the list of criteria leading auto-nomic selection of tactics and model the underlyingpreferences as elasticity strategies reflecting high levelsreconfiguration goals.

AcknowledgmentThis work is supported by SIGMA Informatique

(http://www.sigma.fr).Experiments presented in this paper were carried out

using the Grid’5000 testbed, supported by a scientificinterest group hosted by Inria and including CNRS,RENATER and several Universities as well as otherorganizations (https://www.grid5000.fr).

References[1] N. R. Herbst, S. Kounev, and R. Reussner, “Elasticity in

cloud computing: What it is, and what it is not.” in Int.Conf. on Autonomic Computing (ICAC), 2013, pp. 23–27.

[2] J. Kephart and D. Chess, “The vision of autonomiccomputing,” Computer, vol. 36, no. 1, pp. 41–50, 2003.

[3] G. Galante and L. C. E. d. Bona, “A survey on cloudcomputing elasticity,” in IEEE Int. Conf. on Utility andCloud Computing (UCC), 2012, pp. 263–270.

[4] M. Mao and M. Humphrey, “A performance study onthe vm startup time in the cloud,” in IEEE Int. Conf. onCloud Computing (CLOUD), 2012, pp. 423–430.

[5] H. Jin, X. Wang, S. Wu, S. Di, and X. Shi, “Towardsoptimized fine-grained pricing of iaas cloud platform,”IEEE Transactions on Cloud Computing, 2014.

[6] A. Beloglazov, J. Abawajy, and R. Buyya, “Energy-awareresource allocation heuristics for efficient managementof data centers for cloud computing,” Future GenerationComputer Systems, vol. 28, no. 5, pp. 755–768, 2012.

[7] A. Kejariwal, “Techniques for optimizing cloud foot-print,” in IEEE Int. Conf. on Cloud Engineering (IC2E),2013, pp. 258–268.

[8] A. Lenk and M. Turowski, “Vertical scaling capability ofopenstack - survey of guest operating systems, hypervi-sors, and the cloud management platform,” in Service-Oriented Computing ICSOC 2014, 2014.

[9] Y. Kouki and T. Ledoux, “Rightcapacity: Sla-drivencross-layer cloud elasticity management,” InternationalJournal of Next-Generation Computing, vol. 4, no. 3, 2013.

[10] G. Cugola and A. Margara, “Processing flows of infor-mation: From data stream to complex event processing,”ACM Comput. Surv., vol. 44, no. 3, pp. 15:1–15:62, 2012.

[11] R. Han, L. Guo, M. M. Ghanem, and Y. Guo,“Lightweight resource scaling for cloud applications,”in IEEE/ACM Int. Symp. on Cluster, Cloud and Grid Com-puting (CCGrid), 2012, pp. 644–651.

[12] M. Hasan, E. Magana, A. Clemm, L. Tucker, and S. Gu-dreddi, “Integrated and autonomic cloud resource scal-ing,” in Network Operations and Management Symposium(NOMS), 2012 IEEE, 2012, pp. 1327–1334.

[13] M. Mao, J. Li, and M. Humphrey, “Cloud auto-scalingwith deadline and budget constraints,” in IEEE/ACM Int.Conf. on Grid Computing (GRID), Oct 2010, pp. 41–48.

[14] A. Ali-Eldin, J. Tordsson, and E. Elmroth, “An adaptivehybrid elasticity controller for cloud infrastructures,” inNetwork Operations and Management Symposium (NOMS),2012 IEEE, April 2012, pp. 204–212.

[15] E. Barrett, E. Howley, and J. Duggan, “Applying rein-forcement learning towards automating resource alloca-tion and application scalability in the cloud,” Concur-rency and Computation: Practice and Experience, vol. 25,no. 12, pp. 1656–1674, 2013.

[16] X. Dutreilh, S. Kirgizov, O. Melekhova, J. Malenfant,N. Rivierre, and I. Truck, “Using Reinforcement Learn-ing for Autonomic Resource Allocation in Clouds: to-wards a fully automated workflow,” in Int. Conf. onAutonomic and Autonomous Systems, 2011, pp. 67–74.

[17] F. Teng and F. Magoules, “A new game theoreticalresource allocation algorithm for cloud computing,” inInt. Conf. on Advances in Grid and Pervasive Computing(GPC), 2010, pp. 321–330.

[18] D. Ardagna, B. Panicucci, and M. Passacantando, “Agame theoretic formulation of the service provisioningproblem in cloud systems,” in Int. Conf. on World WideWeb. ACM, 2011, pp. 177–186.

[19] S. Islam, J. Keung, K. Lee, and A. Liu, “Empiricalprediction models for adaptive resource provisioning inthe cloud,” Future Generation Computer Systems, vol. 28,no. 1, pp. 155–162, 2012.

[20] P. Jamshidi, A. Ahmad, and C. Pahl, “Autonomic re-source provisioning for cloud-based software,” in Int.Symp. on Software Engineering for Adaptive and Self-Managing Systems (SEAMS), 2014, pp. 95–104.

[21] L. Wang, J. Xu, M. Zhao, Y. Tu, and J. A. B. Fortes,“Fuzzy modeling based resource management for vir-tualized database systems,” in Int. Symp. on Modelling,Analysis, and Simulation of Computer and Telecommunica-tion Systems, 2011, pp. 32–42.

[22] V. C. Emeakaroha, I. Brandic, M. Maurer, and S. Dustdar,“Low level metrics to high level slas-lom2his frame-work: Bridging the gap between monitored metrics andsla parameters in cloud environments,” in Int. Conf.on High Performance Computing and Simulation (HPCS).IEEE, 2010, pp. 48–54.

[23] D. Garlan, B. Schmerl, and S.-W. Cheng, “Softwarearchitecture-based self-adaptation,” in Autonomic com-puting and networking. Springer, 2009, pp. 31–55.

[24] D. Garlan, S.-W. Cheng, A.-C. Huang, B. Schmerl,and P. Steenkiste, “Rainbow: Architecture-based self-adaptation with reusable infrastructure,” Computer,vol. 37, no. 10, pp. 46–54, 2004.

[25] C. Klein, M. Maggio, K.-E. Årzen, and F. Hernandez-Rodriguez, “Brownout: Building more robust cloud ap-plications,” in Int. Conf. on Software Engineering (ICSE).ACM, 2014, pp. 700–711.

92