Institute of Architecture of Application Systems, University of Stuttgart, Germany,{gomez-saez,andrikopoulos,leymann}@iaas.uni-stuttgart.de

Consolidation of Performance and Workload Models in Evolving Cloud Application Topologies

Santiago Gómez Sáez, Vasilios Andrikopoulos, Frank Leymann

These publication and contributions were presented at CLOSER 2016CLOSER 2016 Web site: http://closer.scitevents.org

© 2016 SciTePress. Personal use of this material is permitted. However,permission to reprint/republish this material for advertising orpromotional purposes or for creating new collective works for resale orredistribution to servers or lists, or to reuse any copyrighted componentof this work in other worksmust be obtained from the SciTePress.

@inproceedings {INPROC-2016-01,author = {Santiago G{\'o}mez S{\'a}ez and Vasilios Andrikopoulos and Frank Leymann},title = {{Consolidation of Performance and Workload Models in Evolving Cloud Application Topologies}},booktitle = {Proceedings of the 6th International Conference on Cloud Computing and Service Science

(CLOSER 2016)},address = {Rome, Italy},publisher = {SciTePress},institution = {University of Stuttgart, Faculty of Computer Science, Electrical Engineering, and Information

Technology, Germany},pages = {160--169},type = {Conference Paper},month = {April},year = {2016},language = {English},cr-category = {C.2.4 Distributed Systems,

D.2.8 Software Engineering Metrics,D.2.11 Software Engineering Software Architectures},

contact = {Santiago G{\'o}mez S{\'a}ez: santiago.gomez-saez@iaas.uni-stuttgart.de},department = {University of Stuttgart, Institute of Architecture of Application Systems},

}

Institute of Architecture of Application Systems

Consolidation of Performance and Workload Models inEvolving Cloud Application Topologies

Santiago Gomez Saez, Vasilios Andrikopoulos, Frank LeymannInstitute of Architecture of Application Systems, University of Stuttgart, Stuttgart, Germany

{gomez-saez, andrikopoulos, leymann}@iaas.uni-stuttgart.de

Keywords:Cloud Application Topology; Cloud Application Distribution; Cloud Application PerformanceEngineering; Cloud Application Workload

Abstract:The increase of available Cloud services and providers has contributed to accelerate the developmentand has broaden the possibilities for building and provisioning Cloud applications in heterogeneousCloud environments. The necessity for satisfying business and operational requirements in an agileand rapid manner has created the need for adapting traditional methods and tooling support forbuilding and provisioning Cloud applications. Focusing on the application’s performance and itsevolution, we observe a lack of support for specifying, capturing, analyzing, and reasoning on theimpact of using di↵erent Cloud services and configurations. This paper bridges such a gap byproposing the conceptual and tooling support to enhance Cloud application topology models tocapture and analyze the evolution of the application’s performance. The tooling support is builtupon an existing modeling environment, which is subsequently evaluated using the MediaWiki(Wikipedia) application and its realistic workload.

1 INTRODUCTION

The existence of a wide technological land-scape o↵ered in the Everything-as-a-Service (*aaS)model has contributed to an increase of applica-tions partially or completely running or built inthe Cloud, potentially as a composition of Cloudservices [Andrikopoulos et al., 2013]. The adop-tion of continuous software delivery models, suchas DevOps, aim at o↵ering flexibility and agilityfor a quick response to market changes. The De-vOps emergence boosted e↵orts in research andindustry towards developing concepts and tools toassist application developers to develop, provision,and (re)deploy cloud applications in a simplified,interoperable, and agile manner.

Standards like TOSCA1 allow the automatedand interoperable provisioning and configurationof Cloud services to host the di↵erent applicationcomponents. However, there exists a lack of native

1Topology and Orchestration Specificationfor Cloud Applications (TOSCA) Version 1.0:http://docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.html

support for assisting application developers in theselection and configuration of appropriate Cloudservices based on a set of business and operationalobjectives. When focusing on the performance ofthe application, such an analysis becomes evenmore complex and wider, as (i) the fluctuation ofthe application workload has an impact on the re-sources demand and QoS, and (ii) the existence ofmultiple applications running on the same physicalenvironment of a provider has an unpredictable im-pact on the o↵ered performance [Gomez Saez et al.,2015]. Towards narrowing such a gap, in [GomezSaez et al., 2014] we proposed a process-based ap-proach aimed at assisting application developersto e�ciently (re)distribute their application com-ponents spanning multiple Cloud o↵erings whilefocusing on fluctuating and evolving workloads andperformance demands. This work materializes thevision described in [Gomez Saez et al., 2014] bydeveloping the concepts for consolidating perfor-mance aspects in Cloud application topologies.The main contributions of this work are:

1. the derivation of a life cycle targeting the spec-ification, analysis, and adaptation of Cloud

MWiki_App: PHP_App

PHP_Module: PHP_Container

Ubuntu_14.04LTS: Virt_Linux

MWiki App: Web_App

IBM_Server: Physical_Server

wikiDB: SQL_DB

consists_of consists_of

Ubuntu_14.04LTS: Virt_Linux

MySQL: SQL_DBaaS

AWS_EC2_m3.xlarge: AWS_EC2

AWS_RDS_m3.large: AWS_RDS

Physical Server IaaS Solution DBaaS Solution

AWS_EBS_gp2: Distr_Storage

uses

interacts_with

AWS_EC2_t2.medium:AWS_EC2

AWS_EBS_gp2: Distr_Storage

uses

KPI W

alt_hosted_on

hosted_on

Alternative Topology Node Topology Node

Application-specific Topology Node

KPI Performance Indicator

W Workload Specification

WW

Apache_Server: Web_Server

MySQL: SQL_RDB_Server

Figure 1: MediaWiki Application Topology Model

applications for evolving workloads and per-formance requirements,

2. the development of the foundations to enrichCloud application topology models with evolv-ing business and operational requirements, andworkload behavioral models,

3. its corresponding tooling support built atopthe TOSCA2 and OpenTOSCA3 specificationand ecosystem, respectively, and

4. the evaluation of the proposed approach usingthe well known MediaWiki4 application andits realistic workload.

The remainder of the paper is structured asfollows. Section 2 presents the background thiswork builds upon. The proposed life cycle forapplication (re)distribution, and the meta-modelsfor enriching Cloud application topologies withevolving performance and workload models arepresented in Section 3. The tooling support ispresented in Section 4, which is then evaluated inSection 5. Section 6 presents related works, andSection 7 conclusions and future work.

2 MOTIVATION &BACKGROUND

Figure 1 depicts multiple viable distributionsof the two-tiered PHP-based MediaWiki5 applica-

2TOSCA: http://docs.oasis-open.org/tosca/TOSCA/v1.0/os/TOSCA-v1.0-os.html

3OpenTOSCA: http://www.iaas.uni-stuttgart.de/OpenTOSCA/

4MediaWiki Application: https://www.mediawiki.org/wiki/MediaWiki

5WikiMedia Foundation: https://wikimediafoundation.org/wiki/Home

Collaborative Loop

Figure 2: Performance Aware Cloud Application(Re)Distribution Process [Gomez Saez, 2014]

tion. The MediaWiki topology breaks the appli-cation stack in two main component groups: (i)application specific components, i.e. each appli-cation tier description, and (ii) the applicationindependent sub-topology/ies (i.e. the ↵- and �-topologies in the terminology of [Andrikopouloset al., 2014a], respectively). The available numberand nature of Cloud o↵erings allows for a par-tial or complete distribution of the applicationcomponents, therefore building a wide spectrumof alternative µ-topologies [Andrikopoulos et al.,2014a]. For instance, it is possible to outsource theMediaWiki front-end tier to a VM-based o↵ering,such as Amazon EC26, and migrate its backenddatabase tier to an o↵-premise EC2 VM or in anAmazon RDS7 database instance.

The existence of such a spectrum of alternativeµ-topologies together with the necessity to rapidlysatisfy changing business and operational require-ments introduces a multi-dimensional problem in-volving the analysis and revision of requirementsand objectives. More specifically, it involves theevaluation of the trade-o↵ between two or moredimensions, e.g. cost vs. performance, etc., duringthe modeling and production phases of the appli-cation. Towards bridging such a gap, in [GomezSaez et al., 2014] and [Andrikopoulos et al., 2014a]we proposed a methodology and formal framework,respectively. Such approaches aim at allowing de-velopers and operation engineers to distribute andredistribute their application components spannedamong multiple Clouds to cope with changing busi-ness and operational requirements, and fluctuating

6AWS EC2: http://aws.amazon.com/ec2/7AWS RDS: http://aws.amazon.com/rds/

workloads.The Performance Aware Cloud

(Re)Distribution Process depicted in Fig-ure 2 consists of several tasks: (i) modeling theapplication topology, (ii) enriching such topologywith business and operational requirements, andthe workload characteristics, which are then(iii) processed and analyzed to subsequently (iv)discover, construct, and evaluate alternativeµ-topologies. The (v) deployment and productionphase of the application assists in building thenecessary knowledge to (vi) analyze the evolutionof the application performance demands andworkload behavior through monitoring techniques.The Collaborative Loop gears towards supportingthe (re-)distribution of the application over timeto rapidly react to changing requirements andfluctuating workloads. This research paperprovides the conceptual and tooling supporttowards supporting the Modeling and Enrichmenttasks in Figure 2.

3 PERFORMANCE-AWAREMODELING & ENRICHMENTOF CLOUD APPLICATIONS

This section presents two fundamental aspectsthat must be taken into consideration for achiev-ing an agile (re)distribution of Cloud applicationsspanning multiple Clouds: (i) the developmentof a life cycle for selecting and configuring Cloudresources to satisfy application business and op-erational requirements, and (ii) the derivation ofthe necessary foundations in the Modeling andEnrichment tasks depicted of the PerformanceAware Cloud Application (Re)Distribution Pro-cess to support the di↵erent phases of the lifecycle.

3.1 Life Cycle

The specification and analysis of the applicationbusiness and operational performance require toconsider two aspects: (i) the di↵erence betweenthe required and o↵ered performance, and (ii) theevolution of the application workload behavior.According to several investigations [Bahga andMadisetti, 2011,Gmach et al., 2007, John et al.,1998,Mian et al., 2013,Watson et al., 2010], twoapproaches can be derived for designing and provi-sioning adaptable Cloud applications w.r.t. chang-ing business and operational requirements, and

KPI Specification

Workload Model Derivation

Workload Evolution & Characterization

Top-down Bo

ttom

-up

Resources Selection & Configuration

Figure 3: Application (Re)Distribution Life Cycle

fluctuating workloads: top-down and bottom-up.The life cycle depicted in Figure 3 supports the(re)distribution of applications w.r.t. their busi-ness and operational requirements. A first phaseconsists of the KPI Specification, by means ofdefining and specifying the business and opera-tional requirements. Together with the specifica-tion and analysis of the application workload in theWorkload Model Derivation phase, the resourcescan be selected and configured in the ResourcesSelection & Configuration phase. However, theprevious phases do not directly enable the analy-sis of the workload fluctuation. Towards such agoal, the Workload Evolution & Characterizationphase allows to analyze the workload evolutionduring the application’s production phase, using,e.g. monitoring techniques.

The execution of the previous phases in thetop-down approach empowers the allocation ofresources to satisfy business and operational re-quirements. The bottom-up approach builds onthe adaptation of resources and in the refinementof business and operational requirements. Thebottom-up approach mainly builds towards deriv-ing the optimal resource allocation and configu-ration w.r.t. the application performance [Mianet al., 2013]. In this work we build towards theconsolidation of the top-down and bottom-up ap-plication workload analysis approaches over timein order to proactively satisfy application demandsby dynamically (re-)adapting its topology.

3.2 KPI RequirementsSpecification

The specification of business and operational re-quirements typically relate to the application’s

Performance Demand Evolution

Application Workload Profile

Workload

- timeInterval

Metric Category

Metric

- name- description

Measure Sample

- size- time interval

Observation

-timestampStatistical Analytical

Indexinfluences

Requirement

- threshold

Application Workload Performance Requirement & Observation

1..*

*

* *

*1..*1..*

*

1..*

is_measured

impact_on

*

evaluates

1..*

-monitoring Resource Reference

Business

Operational

Measure of the correctness of the sample, e.g. accuracy,

confidence level, etc.

Experimental observation, e.g. through

monitoring.

Each requirement fulfillment can be evaluated through

specific metrics

Figure 4: Performance Demand Evolution Meta-model for Cloud Applications

business KPIs, e.g. expected profit, maximum ac-cepted latency to ensure a user’s satisfaction level,etc. The meta-model depicted in Figure 4 estab-lishes the placeholders for the specification andthe analysis of adaptive performance requirementsin the KPI Specification phase of the Application(Re)Distribution Life Cycle. Performance Require-ments can be partitioned in two main correlatedgroups (see Figure 4): Operational Requirementsand Business Requirements. Operational Require-ments relate to the provisioning and configurationof resources, etc., while the Business Requirementsrelate to the business objectives, e.g. expected rev-enue per user, maximum expenditure, etc. BothBusiness and Operational Requirements have oneoverlapping characteristic: Metrics can be used toquantitatively analyze and evaluate the fulfillmentof such requirements (see Figure 4).

In order to simplify the selection of perfor-mance metrics, these can be classified and orga-nized in the proposed meta-model within di↵erentMetric Categories. For instance, there are met-rics which focus on the capacity or utilization ofthe di↵erent types of resources, while others mea-sure discontinuation aspects. Each defined Metriccan be quantitatively analyzed by analyzing itsconstructed Measure Samples. Measure Samplesconsist of a sequence of Observations taken over aperiod of time, retrieved through monitoring tools,and persisted in large analytical repositories forprocessing purposes. The representation of sta-tistical characteristics of the monitored metrics issupported in the proposed meta-model by meansof incorporating Analytical Indexes for each Mea-

sured Sample, e.g. using the standard deviationto measure the data dispersion. The specificationand measurement of the application’s operationaland business performance requirements allows forthe continuous observation of the PerformanceEvolution for the di↵erent Workload Profiles (seeFigure 4).

3.3 Workload Model Derivation &Characterization

The meta-model proposed in the previous sectioncomprised the necessary artifacts for specifyingbusiness and operational requirements of Cloudapplications. However, fluctuating workloads typ-ically have a strong impact on the application’sperformance variability. For such a purpose, inthis section we identify the necessary artifacts andwe derive a the meta-model for enhancing Cloudapplication topologies with workload models. Forthe scope of this work, we define the application’sworkload as the description of a set of businesstransactions which are probabilistically distributedfor a time interval, have an impact on the applica-tion state, and define the behavioral characteristicsof its corresponding users.

The Workload Behavior Specification meta-model depicted in Figure 5 builds upon the work-load description presented in [Van Hoorn et al.,2008], which we enhance for composite Cloud ap-plications. Such meta-model defines the placehold-ers for specifying or building workload behavioralmodels in the Workload Model Derivation andWorkload Evolution & Characterization phases of

Application Workload Profile

1..*

Usage Profile

User

1..*

Arrival Rate

1..*

Business Transactions

1..*

Workload

- timeInterval

construct

execute

Component Protocol

1..*

Performance Demand Evolution

Metric Category

Metric

- name- description

Measure Sample

- size- time interval

Application Workload Performance Requirement & Observation

Workload Mix

1..*

Behavior Model

1..*

Application Model

1..*

Application State

1..*

influences

1..**

*

1..*

impact_on

**

Defined as a Probabilistic Distribution Model, e.g.

normal, poisson, etc.

Workload Operations Ocurrences Probabilities

Figure 5: Workload Behavior Specification

the Application (Re)Distribution Life Cycle (seeFigure 3).

The application’s Workload Profile consists ofa set of Workload samples, each comprising its Us-age Profile, its Workload Mix, and its BehavioralModel. The workload’s Usage Profile describes theevolution of the application’s end Users behavior,in terms of their Arrival Rate and the specificationof concurrent or non-concurrent requests. EveryUser executes a set of Business Transactions sentover a specific transport protocol supported bythe application’s Component Protocol. The setof transactions performed on the application aredistributed within a Workload Mix, based on, e.g.popularity, probability of occurrence, etc., eachhaving an impact on every Application State ofthe Application Model. For example, transitionsbetween Application States originate in the execu-tion of the user’s requests, e.g. log-in operations,Wiki page search, etc. The distribution of requestswithin the workload mix and the distribution ofusers over time define a Behavioral Model, i.e. astatistical model representing the behavioral char-acteristics of users and requests, which can beleveraged in order to drive statistical analyses,categorizations, or estimations.

3.4 Cloud Resources Selection &Reconfiguration

In this section we investigate how Cloud applica-tion topology models can be enhanced with thepreviously depicted knowledge. Since Cloud appli-cation topologies describe the set of components,services, and the relationships among them, theenrichment support must take into considerationthe di↵erent levels where Cloud application topol-ogy models can be enriched. The remaining ofthis section outlines in a fined granular mannersuch possibilities.

Due to the generic nature of GENTL amongdi↵erent Cloud application topology languages,we use it as the basis for analyzing the modelingand enrichment points of Cloud application topol-ogy models [Andrikopoulos et al., 2014b] (see Fig-ure 6). KPI requirements and workload behavioralcharacteristics can be fundamentally specified intwo granular ways. A fined granular descriptionconsits of decomposing and describing the perfor-mance requirements and workload characteristics,respectively, e.g. on the topology Component orRelationship levels. For instance, the usage ofdi↵erent storage services to store application data,such as AWS S38 or AWS RDS, may require finedgranular description of the workload operations

8AWS S3: http://aws.amazon.com/s3

Performance Demand Evolution

Cloud Application

*

Component GroupConnector

*

Topology

1..11..1

target

**

source1..1 0..1 0..10..1 0..1

Application Workload Profile Metric Category Requirement

- threshold

* 1..*1..*

Figure 6: Application Topology Enrichment with Performance and Workload Models

for each topology Component independently, dueto the di↵erent nature of such data services. Re-lations among the topology components depictedas Connectors have a significant impact in theoverall performance of applications, as they areusually impacted by the network configurationand characteristics. The specification of perfor-mance information in sub-topologies enables togroup reusable Cloud components and serviceswith common KPI requirements and workloadbehavioral characteristics.

The enhancement of Cloud application topolo-gies with KPI requirements and workload informa-tion can be leveraged during the design, provision-ing, and production phases of the application forpredicting and analyzing the performance of Cloudo↵erings. Such information can be leveraged infuture decision making tasks towards assistingapplication developers to select, configure, anddynamically adapt Cloud resources.

4 ARCHITECTURE &IMPLEMENTATION

In the following we discuss the tooling supportto support Cloud application developers in theModeling and Enrichment tasks of performance-aware Cloud application topologies. Due to thehigh adoption of the TOSCA standard in both theindustry and research domain, we build the tech-nological support atop of the TOSCA specifica-tion and its corresponding modeling environmentOpenTOSCA Winery [Kopp et al., 2013].

PERFinery - an OpenTOSCA Winery Ex-tension PERFinery9 is a TOSCA-based model-ing environment geared towards the enrichment ofTOSCA-based Cloud application topologies withevolutionary performance requirements and work-load models.

The specification of non-functional require-ments of Cloud applications is supported inTOSCA by attaching custom policies to the appli-cation topology, typically conforming to the Pol-icy4TOSCA definition [Waizenegger et al., 2013].Policy4TOSCA enables the definition of PolicyTypes and Policy Templates comprising actionswhich must be performed at concrete phases ofthe application life cycle and on specific layers ofthe application. However, Policy4TOSCA lacksof tooling support and does not capture evolvingperformance information, such as the influence ofworkloads on the fulfillment of KPI requirements.The topology enrichment support in this workempowers the current TOSCA policy definitionsupport by enabling the graphical creation of cus-tom Policies comprising the di↵erent measurableand analyzable application requirements.

Figure 7 depicts the architecture of PERFin-ery, and highlights the components that have beenextended in Winery. The Topology Elements Man-ager, Topology and Plan Modeler, and the Repos-itories are the major components (see Figure 7).The Topology Elements Manager enables the ad-ministration and management of reusable artifactsamong multiple topology templates, e.g. NodeTypes, Relationship Types, or Deployment Arti-

9PERFinery Modeling Environment: http://www.iaas.uni-stuttgart.de/PERFinery/

Topology Modeler

Services Manager

GUI

Workload Manager

GUI

Policy Manager

GUI

Repository Manager

CSAR ImporterCSAR Exporter

Workload Repository

Topology Repository

Policy Repository

Figure 7: PERFinery Modeling Environment Ar-chitecture (extended from [Kopp et al., 2013])

facts. The Topology Modeler provides the mod-eling artifacts towards designing and visualizingCloud application topologies. PERFinery com-prises repositories for storing Cloud applicationtopology models and reusable artifacts. The mod-eling elements are provided through the Topol-ogy Modeler and Element Manager client-sideGUIs developed using Java Web technologies andHTML5 (see Figure 7). Moreover, a REST inter-face is also o↵ered atop of the Topology Repositoryfor persisting and retrieving TOSCA artifacts,e.g. CSAR packages. The generated TOSCA andPolicy4TOSCA templates, and workload specifica-tions, as well as the corresponding CSAR packages,are persisted in separate repositories. The persis-tence of workload models is driven and persisted inan independent Workload Repository. Generatedworkloads can be used towards enriching modeledapplication topologies with their behavioral char-acteristics, e.g. user arrival rate, transactions’ mixand distribution of requests, etc.

Application topology and workload models canbe created, viewed, and modified by navigatingthrough the repository and the di↵erent sectionsthat PERFinery o↵ers. For instance, Figure 8depicts the topology model created for the Me-diaWiki application used for the motivation ofthis work, which is subsequently enhanced withperformance information.

5 EVALUATION

We evaluate our approach using the MediaWiki(Wikipedia) application and its realistic workloadprovided in [Urdaneta et al., 2009]. The Medi-aWiki front-end tier encapsulates the presentationand business logic layers, while its back-end pro-vides its persistency mechanisms. We used the

Table 1: Workload Characteristics

Operation Type #Requests Ratio

Read 199925 99.96%Write 75 0.04%

Image Retrieval 8971 4.49%Skins Retrieval 66926 33.46%

Wiki Pages Retrieval 106347 53.17%Others 7634 3.81%

workload provided in Wikibench10 for describingthe workload. Figure 8 shows the view for buildingcustom performance Policy Profiles.

W.r.t. the workload specification, a first stepconsisted of sampling 200K HTTP requests of theoriginal WikiBench workload describing the char-acteristics depicted in Table 1. However, sucha workload sample is not distributed among thedi↵erent users. For this purpose, the workloadsample is referenced in PERFinery together withthe specification of its behavioral characteristics,as depicted in Figure 9, respectively. More specif-ically, the workload model is specified in CSVformat and comprises multiple users arriving atdi↵erent time intervals and executing a set of re-quests mixes defined in the workload sample.

The extensions realized in Winery serve asthe basis for enriching TOSCA topologies withperformance information. More specifically, itprovides Cloud application developers with themeans to graphically include QoS information asTOSCA policies and workload descriptors.

6 RELATED WORK

Most analytical approaches and frameworksin the literature focus on combining operationalexpenses analysis with one or more dimensionspertaining to performance as part of their missionto support Cloud application developers.

DADL is presented in [Mirkovic et al., 2010]as a language to describe the architecture, be-havior and needs of a distributed application tobe deployed in the Cloud, as well as describingavailable Cloud o↵erings for matching purposes.Similarly, in [Antonescu et al., 2012], the au-thors propose a policy and action-based approachthat matches and dynamically adapts the alloca-tion of infrastructure resources to an applicationtopology in order to ensure SLAs. The Cloud-Mig [Frey and Hasselbring, 2011] approach builds

10Wikibench Project: http://www.wikibench.eu/

Figure 8: PERFinery Modeler — Specification of Performance Requirements

Figure 9: PERFinery Modeler — Workload Behav-ioral Model Specification

on an initial topology and utilization model of theapplication that is mapped or adapted throughmodel transformation in order to optimize thedistribution of the application across Cloud o↵er-ings. The MODACloud [di Nitto et al., 2013] andCloudML [Brandtzæg et al., 2012] projects focuson providing a multi-dimensional early design sup-port of applications by applying model transfor-mation techniques and code generation for multi-cloud applications. Further multi-cloud applica-

tion distribution approaches are targeted by theSeaClouds EU Project11, by means of providing aCloud Service Orchestrator capable of provisioningand managing application components spannedamong multiple Cloud environments [Brogi et al.,2014]. The CACTOS EU Project12 is possibly theclosest approach to the fundamentals developedas part of this work. The CACTOS environmentaims at fitting resources within a provider for di-verse application workloads. However, all previousapproaches introduce complex tasks, e.g. creationof simulation models, which often require the in-tervention of domain experts, causing an overheadin the development and (re)deployment tasks ofapplications. Moreover, the relationship of topol-ogy models with varying application workloads isnot yet fully covered.

Further optimization of distribution of applica-tions like the Palladio-based approach discussedin [Miglierina et al., 2013] aims at optimizing foravailability and operational expenses. Moreover,optimization mechanisms are based on simulationtechniques requiring the definition of their corre-sponding models. The MOCCA framework [Ley-

11SeaClouds EU Project: http://www.seaclouds-project.eu/project.html

12Cactos EU Project: http://www.cactosfp7.eu/

mann et al., 2011] deals with the same problemby introducing variability points in the applica-tion topology in order to cope with possible al-ternative deployment topologies. CMotion [Binzet al., 2011] uses an approach based on topol-ogy modeling, generation of alternative topologies,and consequent evaluation and selection of oneof those alternatives based on multiple criteria.The work in [Andrikopoulos et al., 2014a] uses thenotion of typed graphs for similar purposes andproposes a formal framework to support this e↵ort.In a similar approach, MADCAT [Inzinger et al.,2014] incorporates to the topology model scalabil-ity elements, and refines the topology model froma high-level application topology to a ready fordeployment one.

The vision this paper pursues aims at lever-aging existing non-functional requirement speci-fication approaches, such as the ones previouslydiscussed, towards providing the conceptual foun-dations to specify the performance aspects andanalyze the impact of fluctuating workloads forvarious Cloud application distribution and con-figuration alternatives in a simplified manner byenriching Cloud application topology models.

7 CONCLUSIONS ANDFUTURE WORK

The heterogeneity of available Cloud serviceshas become a challenge for application developerswhen considering a rapid and e�cient selectionand configuration of Cloud o↵erings. Applicationcomponents can be distributed or replaced by dif-ferent Cloud services, potentially spanned amongmultiple Clouds. Focusing on the business andoperational performance of Cloud applications,there currently exists a lack of modeling and de-cision making support for capturing, analyzing,and assessing when migrating, configuring, andutilizing di↵erent Cloud services under fluctuatingworkloads and intermittent QoS levels.

The assessment of, and guidance in the dis-tribution of multi-Cloud applications is the coremotivation behind this work. We build towardsenabling the e�cient (re-)distribution of Cloudapplications by means of selecting and configuringCloud o↵erings to cope with fluctuating workloadsand evolving performance demands. The first steptowards such a goal is covered in this work byproviding the means for the enhancement of ap-plication deployment models with performanceinformation and workload behavioral character-

istics. This work tackles the various phases ofour proposed application performance-aware ap-plication (re)distribution life cycle by establishingthe foundations and tooling support for enhancingCloud application topology models with evolvingperformance requirements and workload models.For this purpose, we propose a conceptual modelaimed at enriching Cloud application topologieswith evolving performance requirements and work-load behavioral characteristics, which can used asthe basis for capturing and analyzing the perfor-mance and workload evolution when distributingthe application components among di↵erent Cloudservices. The technological support developedin this work builds upon the TOSCA and Pol-icy4TOSCA specifications, and its correspondingtooling support is built atop the Winery model-ing environment of the OpenTOSCA ecosystem,which is then evaluated using the well known Me-diaWiki application and its realistic workload.

Future investigations are aligned to the de-velopment process of the tool chain depictedin [Gomez Saez et al., 2014], and to reuse or realize,when deemed necessary, the concepts and instru-mentation support to gather, aggregate, and auto-mate the analysis and application (re-)distributionassessment tasks.

ACKNOWLEDGEMENTS

This work is partially funded by the FP7 EU-FET project 600792 ALLOW Ensembles and theGerman 610872 DFG Project SitOPT.

REFERENCES

[Andrikopoulos et al., 2013] Andrikopoulos, V., Binz,T., Leymann, F., and Strauch, S. (2013). Howto Adapt Applications for the Cloud Environment.Computing, 95(6):493–535.

[Andrikopoulos et al., 2014a] Andrikopoulos, V.,Gomez Saez, S., Leymann, F., and Wettinger, J.(2014a). Optimal Distribution of Applications inthe Cloud. In Jarke, M., Mylopoulos, J., and Quix,C., editors, Proceedings of CAiSE’14, pages 75–90.Springer.

[Andrikopoulos et al., 2014b] Andrikopoulos, V.,Reuter, A., Gomez Saez, Santiago, and Leymann,F. (2014b). A GENTL Approach for Cloud Appli-cation Topologies. In Proceedings of ESOCC’14,pages 148–159. Springer.

[Antonescu et al., 2012] Antonescu, A.-F., Robinson,P., and Braun, T. (2012). Dynamic topology or-

chestration for distributed cloud-based applications.In Proceedings of NCCA’12, pages 116–123.

[Bahga and Madisetti, 2011] Bahga, A. and Madis-etti, V. K. (2011). Synthetic Workload Generationfor Cloud Computing Applications. Journal of Soft-ware Engineering and Applications, 4:396–410.

[Binz et al., 2011] Binz, T., Leymann, F., andSchumm, D. (2011). CMotion: A Framework forMigration of Applications into and between Clouds.In Proceedings of SOCA’11, pages 1–4. IEEE Com-puter Society.

[Brandtzæg et al., 2012] Brandtzæg, E., Mohagheghi,P., and Mosser, S. (2012). Towards a domain-specific language to deploy applications in theclouds. In Proceedings of CLOUD COMPUT-ING’12, pages 213–218. IARIA.

[Brogi et al., 2014] Brogi, A., Ibrahim, A., Soldani, J.,Carrasco, J., Cubo, J., Pimentel, E., and D’Andria,F. (2014). Seaclouds: a european project on seam-less management of multi-cloud applications. ACMSIGSOFT Software Engineering Notes, 39(1):1–4.

[di Nitto et al., 2013] di Nitto, E., Silva, M. A. A. d.,Ardagna, D., Casale, G., Craciun, C. D., Ferry, N.,Muntes, V., and Solberg, A. (2013). Supporting thedevelopment and operation of multi-cloud applica-tions: The modaclouds approach. In Proceedings ofSYNASC’13, pages 417–423. IEEE.

[Frey and Hasselbring, 2011] Frey, S. and Hassel-bring, W. (2011). The cloudmig approach: Model-based migration of software systems to cloud-optimized applications. International Journal onAdvances in Software, 4(3 and 4):342–353.

[Gmach et al., 2007] Gmach, D., Rolia, J.,Cherkasova, L., and Kemper, A. (2007). WorkloadAnalysis and Demand Prediction of EnterpriseData Center Applications. In Proceedings ofIISWC’07, pages 171–180.

[Gomez Saez, 2014] Gomez Saez, S. (2014). DesignSupport for Performance-aware Cloud Application(Re-)Distribution. In Proceedings of ESOCC’2014,pages 6–11. Jenaer Schriften zur Mathematik undInformatik.

[Gomez Saez et al., 2015] Gomez Saez, S., An-drikopoulos, V., Hahn, M., Karastoyanova, D., Ley-mann, F., Skouradaki, M., and Vukojevic-Haupt, K.(2015). Performance and Cost Evaluation for theMigration of a Scientific Workflow Infrastructureto the Cloud. In Proceedings CLOSER’2015, pages352–361. SciTePress.

[Gomez Saez et al., 2014] Gomez Saez, S., An-drikopoulos, V., Leymann, F., and Strauch, S.(2014). Design Support for Performance AwareDynamic Application (Re-)Distribution in theCloud. IEEE Transactions on Services Comput-ing, 8(2):225–239.

[Inzinger et al., 2014] Inzinger, C., Nastic, S., Sehic,S., Vogler, M., Li, F., and Dustdar, S. (2014).MADCAT A Methodology for Architecture and

Deployment of Cloud Application Topologies. InProceedings of SOSE’14. IEEE.

[John et al., 1998] John, L. K., Vasudevan, P., andSabarinathan, J. (1998). Workload Characteriza-tion: Motivation, Goals and Methodology. In Pro-ceedings of WWC’98.

[Kopp et al., 2013] Kopp, O., Binz, T., Breit-enbucher, U., and Leymann, F. (2013). Winery- A Modeling Tool for TOSCA-based Cloud Appli-cations. In Proceedings of ICSOC’13, volume 8274of LNCS, pages 700–704. Springer Berlin Heidel-berg.

[Leymann et al., 2011] Leymann, F., Fehling, C., Mi-etzner, R., Nowak, A., and Dustdar, S. (2011).Moving applications to the cloud: An approachbased on application model enrichment. Interna-tional Journal of Cooperative Information Systems,20(03):307–356.

[Mian et al., 2013] Mian, R., Martin, P., andVazquez-Poletti, J. L. (2013). Provisioning DataAnalytic Workloads in a Cloud. FGCS, 29:1452–1458.

[Miglierina et al., 2013] Miglierina, M., Gibilisco, G.,Ardagna, D., and Di Nitto, E. (2013). Model basedcontrol for multi-cloud applications. In Proceedingsof MiSE’13, pages 37–43.

[Mirkovic et al., 2010] Mirkovic, J., Faber, T., Hsieh,P., Malaiyandisamy, G., and Malaviya, R. (2010).DADL: Distributed Application Description Lan-guage. Technical Report ISI-TR-664, USC/ISI.

[Urdaneta et al., 2009] Urdaneta, G., Pierre, G., andvan Steen, M. (2009). Wikipedia workload anal-ysis for decentralized hosting. Elsevier ComputerNetworks, 53(11):1830–1845.

[Van Hoorn et al., 2008] Van Hoorn, A., Rohr, M.,and Hasselbring, W. (2008). Generating prob-abilistic and intensity-varying workload for web-based software systems. In Performance Evaluation:Metrics, Models and Benchmarks, pages 124–143.Springer.

[Waizenegger et al., 2013] Waizenegger, T., Wieland,M., Binz, T., Breitenbucher, U., Haupt, F., Kopp,O., Leymann, F., Mitschang, B., Nowak, A., andWagner, S. (2013). Policy4TOSCA: A Policy-AwareCloud Service Provisioning Approach to EnableSecure Cloud Computing. In OTM’13.

[Watson et al., 2010] Watson, B. J., Marwah, M.,Gmach, D., Chen, Y., Arlitt, M., and Wang, Z.(2010). Probabilistic Performance Modeling of Vir-tualized Resource Allocation. In Proceedings ofICAC’10.