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

© 2014 SciTePress. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the SciTePress.

@inproceedings{Breitenbuecher2014_CLOSER, author = {Uwe Breitenb{\"u}cher and Tobias Binz and Oliver Kopp and Frank Leymann and Matthias Wieland}, title = {Context-aware Cloud Application Management}, booktitle = {Proceedings of the 4th International Conference on Cloud Computing and Services Science (CLOSER)}, year = {2014}, pages = {499-509}, publisher = {SciTePress} }

:

Institute of Architecture of Application Systems

Institute of Architecture of Application Systems, University of Stuttgart, Germany,

lastname@iaas.uni-stuttgart.de

Context-aware Cloud Application Management

Uwe Breitenbücher, Tobias Binz, Oliver Kopp, Frank Leymann, Matthias Wieland

Context-Aware Cloud Application Management

Uwe Breitenbucher, Tobias Binz, Oliver Kopp, Frank Leymann, Matthias WielandInstitute of Architecture of Application Systems, University of Stuttgart, Stuttgart, Germany

{breitenbuecher, lastname}@iaas.uni-stuttgart.de

Keywords: Application Management, Context, Automation, Cloud Computing

Abstract: The automation of application management is one of the most important issues in Cloud Computing. However,the steadily increasing number of different services and software components employed in composite Cloudapplications leads to a higher risk of unexpected side effects when different technologies work together thatbring their own proprietary management APIs. Due to unknown dependencies and the increasing diversity andheterogeneity of employed technologies, even small management tasks on single components may compromisethe whole application functionality for reasons that are neither expected nor obvious to non-experts. In thispaper, we tackle these issues by introducing a method that enables detecting and correcting unintended effectsof management tasks in advance by analyzing the context in which tasks are executed. We validate the methodpractically and show how context-aware expert management knowledge can be applied fully automatically torunning Cloud applications.

1 INTRODUCTION

In recent years, Cloud Computing gained a lot ofattention due to its economical and technical benefits.Especially properties such as pay-on-demand comput-ing, self-service, and elasticity enable enterprises tooutsource IT (Leymann, 2009). These properties arekey success factors for both Cloud providers as wellas customers. To exploit these properties reliably fortheir offerings, Cloud providers have to automate theirinternal processes for application provisioning, con-figuration, and management. Therefore, a lot of tools,methods, and technologies have been developed in thepast years: Script-centric DevOps communities sup-port automated configuration management, guidelinessuch as the Information Technology Infrastructure Li-brary (ITIL) (Malone et al., 2008) help applying bestpractices to IT service management, and standardssuch as TOSCA (OASIS, 2013) enable applicationdevelopers to describe applications and their manage-ment in a portable way—to name a few examples.However, automating management tasks on complexCloud applications becomes a more and more diffi-cult challenge: The increasing number and diversityof employed Cloud services on various layers offeredby different Cloud providers leads to a higher riskof unexpected side effects when they are combinedwith each other or integrated with traditional software

components and middleware systems. Additional com-plexity arises from the heterogeneity of managementtechnologies: Cloud providers, middleware systems,and software components often provide proprietarymanagement APIs, security mechanisms, and data for-mats (Breitenbucher et al., 2013b). Thus, if a task af-fects multiple different parts of an application, also themanagement technologies of these parts may need tobe integrated. This requires (i) a deep technical insightin each part and management technology as well as(ii) an overall understanding of the whole system andpossible impacts to avoid errors. In these scenarios, of-ten only experts of the respective technology are ableto execute management tasks correctly. However, alsoexperts reach their limits when a management task hasto be executed on a complex application whose exactstructure and runtime information are not documented:Unknown relations and dependencies between compo-nents that directly influence each other’s functionalitylead to a serious management challenge. Even if only asmall operation has to be executed on a single compo-nent, its impact on other components is not predictableseriously if the application’s structure is not knownexactly. Thus, if the context, in which a managementtask is executed, is not known, understood, and con-sidered, there is a high risk of unexpected side effectsthat may compromise the application’s functionality.In addition, as executing management task manually

is slow, costly, and error prone, Cloud applicationmanagement must be automated to enable Cloud prop-erties (Fehling et al., 2012; Oppenheimer et al., 2003).As a result, in case multiple heterogeneous Cloud ser-vices, software components, and middleware systemsare involved and different management technologieshave to be orchestrated, it’s of vital importance to (i)apply expert management knowledge, (ii) consider thecontext in which tasks are executed, and (iii) automatemanagement processes to avoid manual errors.

In this paper, we tackle these issues. We presentan approach that enables applying expert managementknowledge for tasks in a certain context automaticallyto running Cloud applications. Therefore, we intro-duce an abstract (i) Context-Aware Application Man-agement Method and (ii) present a fully automatedrealization of this method for Cloud Computing tovalidate its practical feasibility. The method intro-duces Declarative Management Description Models(DMDM) to describe management tasks declarativelyincluding their context in a formal model. This en-ables experts to detect unintended impacts and sideeffects of management tasks through analyzing themin the context in which they are executed. We showthat an individual context analysis is required for manymanagement tasks on Cloud applications due to theheterogeneous nature of the involved components andmanagement technologies—which is not possible hav-ing traditional imperative models such as workflows orscripts as these models describe only the task-specificinformation but not the context in which they are ex-ecuted. The presented automated realization of themethod for Cloud application management validatesthe method’s practical feasibility. It enables Cloudproviders to offer a variety of different Cloud applica-tions consisting of heterogeneous components withoutthe need to employ or educate specialized experts thathave the required technical management knowledge.

The remainder of this paper is structured as follows:In Section 2, we describe a motivating scenario toexplain the method, which is introduced in Section 3.Section 4 presents the automated realization of themethod to validate its practical feasibility for Cloudapplication management. In Section 5 we give anoverview on related work. Section 6 concludes thepaper and gives an outlook on future work.

2 MOTIVATION

In this section, we describe the problem tackledby our approach in detail and introduce a motivatingscenario that is used throughout the paper to explainthe presented method and its realization.

2.1 Problem Statement

In this section, we describe the major issues of Cloudapplication management and why context considera-tion is of vital importance in this area. Due to differentfunctional as well as non-function requirements onservices, Cloud offerings of different providers oftenhave to be integrated as using a single Cloud providerfor the complete application landscape of a company isoften not possible (Fehling et al., 2012). The focus ofthis paper lies, therefore, on the management of Com-plex Composite Cloud Applications, which consist ofmultiple heterogeneous Cloud services, software com-ponents, and middleware systems of different vendorsand Cloud providers.

The management of such applications is quite dif-ficult as it requires a deep technical understanding ofthe involved components, the dependencies betweenthem, and their management technologies—which aremost often proprietary implementations providing het-erogeneous management interfaces (Leonhardt, 2013).As a consequence, human-induced failures accountfor a significant number of outages as human errorsaccompany even the simplest system operation andmanagement tasks (Brown and Patterson, 2001). Themanagement flexibility recently introduced by CloudComputing has additionally increased this effect asmanagement tasks, such as the provisioning of newvirtual machines, are literally at the systems manager’sfingertips and often handled completely via proprietarymanagement interfaces offered by Cloud providers(Fehling et al., 2012). Due to this management evolu-tion, human errors are more likely to occur since thephysical infrastructure and thereon deployed softwaresystems are often virtualized and, therefore, obfus-cating the actual structure of an application. Thus,it becomes more and more difficult to consider thecontext, in which management tasks are executed, cor-rectly as application structures, system boundaries,and dependencies are becoming increasingly blurredby the Cloud. In addition, due to the lack of interoper-ability between Cloud services of different providersand traditional software components, most often com-plex configuration management is needed to integrateheterogeneous systems. As a result, executing man-agement tasks which affect multiple parts of an appli-cation at once requires special management expertise.These problems impede automating Cloud applica-tion management, which is a major requirement forefficient use of Cloud resources and to avoid man-ual human errors (Fehling et al., 2012; Oppenheimeret al., 2003). Therefore, we need a means to captureand apply context-aware management expertise fullyautomatically to running Cloud applications.

2.2 Management Automation

To automate application management, the executionof management tasks is often described imperativelyusing executable processes implemented as work-flows (Leymann and Roller, 2000) in languages such asBPEL (OASIS, 2007) or BPMN (OMG, 2011), scriptssuch as bash, or programs implemented in a computerprogramming language such as Java. Especially themore and more emerging script-centric configurationmanagement technologies such as Chef (Nelson-Smith,2013) are prime examples for this kind of imperativemanagement descriptions. However, if an applicationis crucial to the business of an enterprise, errors thatpossibly result in system downtime are not accept-able. Therefore, before executing such managementprocesses, they must be verified by experts to ensurecorrectness. Unfortunately, one of the most importantproblems of this approach is that the context, in whichthe management tasks are executed, is not explicitlydescribed and, thus, not visible in such processes. Asa result, management processes cannot be analyzedby experts in consideration of the management tasks’context as only operation calls, service invocations, orscript executions on the directly affected componentsare described, but not the surrounding environment:Experts see only the directly affected part of the ap-plication, not the whole application structure. Thus,other application components that may be affected in-directly, too, cannot be considered in this analysis. Forexample, if the database of a Web-based applicationshall be replaced by a database from a different ven-dor, the application’s Web server may require a certaindatabase connector to be installed for connecting tothe new database. If this dependency is not consideredand handled by the management process replacing thedatabase through installing the required new connec-tor, too, the application cannot connect to its databaseanymore. This quickly results in system downtimescaused by errors that are neither easy to find nor tofix. Thus, the most important requirement to enablecontext-aware management is a formal model that de-scribes both the tasks and the context.

2.3 Motivating Scenario

In this section, we describe the motivating scenariothat is used throughout the paper to explain the pro-posed method and its realization. The scenario de-scribes a business application that consists of a PHP-based Web frontend and a PostgreSQL database. Thefrontend should be migrated from one Cloud to an-other. Because the application evolved over time, itis currently distributed over two Clouds: The PHP

frontend is hosted on Microsoft’s public Cloud offer-ing “Windows Azure”1, the PostgreSQL database onAmazon’s PaaS offering “Relational Database Service(RDS)”2, which enables hosting databases directly asa service. The PHP frontend runs on an Apache HTTPServer (including the PHP-module) which is installedon an Ubuntu Linux operating system that runs in a vir-tual machine hosted on Azure. The management taskthat has to be executed is migrating the PHP frontendto Amazon’s IaaS offering “Elastic Compute Cloud(EC2)”3 in order to reduce the number of employedCloud providers. This migration results in two issuesthat compromise the application’s functionality if theyare not considered by experts having the knowledgeto recognize the following two problems in advance:(i) missing database driver and (ii) missing configu-ration of the database service. To migrate the PHPfrontend, we have to create a new virtual machine onAmazon EC2, install the Apache HTTP Server andthe PHP-module, and deploy the corresponding PHPfiles on it. This works without further configurationissues. However, connecting the PHP application tothe database is not as easy as it seems to be: Simplydefining the database configuration of the PHP fron-tend by setting the database’s endpoint, username, andpassword is not sufficient. Here, a technical detailof the underlying infrastructure needs to be consid-ered: The PHP-module of the Apache HTTP Serverneeds different database drivers to connect to differenttypes of databases. Thus, if the PostgreSQL drivergets not installed explicitly on the server, the MoodlePHP frontend is not able to connect to the database.However, this is not easy to recognize as applicationsoften employ MySQL databases whose drivers are typ-ically installed together with the PHP-module. Thus,installing the required driver for PostgreSQL might beforgotten. The second issue is even more difficult toforesee if the administrator is not an expert on Ama-zon RDS: Databases running on Amazon RDS areper default not accessible from external components.To allow connections, a so-called “Security Group”must be defined to configure the firewall. This groupspecifies the IP-addresses which are allowed to con-nect to the database. Both issues result in breakingthe application’s functionality as the frontend cannotconnect to the database. The reason for both prob-lems lies in ignoring the context in which the tasksare executed: First, if an application shall connect toa certain type of database, the runtime environmenthosting the application must support connecting to thiskind of database. It is not enough to simply set the

1http://www.windowsazure.com/2http://aws.amazon.com/rds/3http://aws.amazon.com/ec2/

configuration as the underlying infrastructure, i. e., thecontext, needs to be considered, too. Second, access-ing a database hosted on Amazon RDS requires alsomore than simply writing endpoint information into aconfiguration file as also the firewall of the service hasto be configured. Thus, also for this task, the contextin the form of the infrastructure that hosts the databasehas to be considered to recognize the problem.

However, both problems cannot be detected byexperts if the migration is implemented using tradi-tional approaches such as management workflows orscripts: The processes would only model the steps for(i) shutting down the old virtual machine on Azure,(ii) creating the new virtual machine on Amazon EC2,(iii) installing the Apache Web Server and the PHP-module, (iv) deploying the frontend, and (v) settingthe database’s IP-address, username, and password inthe frontend’s configuration. The process neither pro-vides information about the database’s type nor whichinfrastructure is used to host the database—the contextis not described. In addition, if administrators executethis migration manually, they require a lot of technicalexpertise and background information about the differ-ent APIs and employed technologies. Thus, we needa means to (i) capture expert management knowledgefor a certain context and (ii) make it applicable fullyautomatically in order to help administrators avoidingunintended mistakes.

3 CONTEXT-AWAREMANAGEMENT METHOD

In this section, we introduce the Context-Aware Ap-plication Management Method that provides a meansto consider the context in which management tasks onapplication components or relationships are executed.The method separates between a declarative descrip-tion of the management tasks to be executed and thefinal executable management process. It consists ofsix steps which are shown in Figure 1: First, (1) wecapture all runtime information and the structure of theapplication to be managed in a formal model which isextended in the second step (2) by declaring tasks oncomponents and relations. In the third step, (3) expertsanalyze this model for unintended side effects and (4)adapt the model afterwards if necessary to resolve thefound problems. In the fifth step, (5) this declarativemodel is translated into an imperative process modelthat is executed in the last step (6) to perform the taskson the running application. We explain each step in thefollowing subsections and start each description witha short summary of the step in italic text to provide acompact overview that is detailed afterwards.

Context-Aware Application Management

Method

1. Capture Application as Formal Model

2. Create Declarative

Management Description

Model

3. Analyze Declarative

Management Description

Model

4. Adapt Declarative

Management Description

Model

5. Create Imperative

Management Description

Model

6. Execute Imperative

Management Description

Model

Figure 1: Context-Aware Application Management Method.

3.1 Step 1: Capture Application asFormal Model

Describe all components of the application and theirrelations in a formal model that specifies their typesand current runtime information.

First, the application to be managed is described asa formal model. This model captures the applicationstructure and its state, i. e., all components such as Webservers, virtual machines, or installed applications, therelations between them, e. g., database connections,and their runtime information. The semantics of com-ponents and relations (we call both model elementsin the following) are described using types, e. g., acomponent may be of type “ApacheHTTPServer”, arelationship of type “SQLConnection”. To enablea precise definition of the model elements, typescan be inherited: the “ApacheHTTPServer” type isa subtype of “HTTPServer”. Runtime informationare described as model element properties, e. g., the“ApacheHTTPServer” has properties “IP-Address” and“Port” that specify the server’s endpoint. The propertyschema is defined by the type of the model element.This formalization of the running application providesa detailed, structured, and machine readable means todocument a current snapshot of the application struc-ture and all runtime information.

3.2 Step 2: Create DeclarativeManagement Description Model

Create a Declarative Management Description Modelthat declaratively describes the management tasks tobe executed on components and relations.

In the second step, the desired management tasks aredescribed based on the formal model. Therefore, weintroduce the Declarative Management DescriptionModel (DMDM) that extends the formal model cap-tured in Step 1 by a declarative description of themanagement tasks to be executed on components andrelations of the application. This model declares man-agement tasks in an abstract manner without technicalimplementation details and specifies the target com-ponent or relation of each task. A DMDM is not exe-cutable as it describes only what has to be done, butnot how—all technical details are missing. For ex-ample, a DMDM may declare a “Create” task on arelation of type “SQLConnection” between a PHP ap-plication and an SQL database, which means that theconnection has to be established. However, it providesneither technical implementation details nor specifiesthe control flow between multiple different tasks.

3.3 Step 3: Analyze DeclarativeManagement Description Model

Analyze the impact of tasks in consideration of thecontext defined by the components, relations, andruntime information described by the DMDM.

The DMDM created in the previous step captures asnapshot of the application and the abstract manage-ment tasks to be executed. The model describes thewhole context in which tasks are executed by mod-elling all components and adjacent relations of theapplication that are possibly affected. In the third step,management tasks are analyzed in their context by ex-perts of different domains to detect unexpected impactsleading to unintended side effects. DMDMs enablecooperation between different experts and separateconcerns based on a uniform, structured, and formalmodel: Experts on the “ApacheHTTPServer” are ableto detect that the installation of a certain database con-nector is required, experts on the Amazon Cloud areable to configure the Security Group in order to allowconnections from the external PHP frontend of the ap-plication. Thus, DMDMs can be analyzed by multipleexperts of different domains in a cooperative manner.

3.4 Step 4: Adapt DeclarativeManagement Description Model

Adapt the analyzed Declarative Management Descrip-tion Model if necessary to solve the analyzed problems.

After the expert analysis, found problems have to beresolved in order to achieve the desired managementgoals. Therefore, the DMDM is adapted in this step bythe respective experts to enable correct execution of themanagement tasks. Therefore, components, relations,and tasks of the DMDM may be added or reconfigured.For example, the missing database connector found inthe analysis of the previous step is resolved by addingthe task to install the required connector on the WebServer. Thus, each task was verified in its respectivecontext in the previous step and gets corrected if nec-essary in this step. However, if tasks are added orreconfigured, all tasks have to be analyzed again forcorrectness as the context changed by this adaptation.This may lead to new problems and unintended sideeffects on other components or relations that have tobe found. Therefore, Step 3 and Step 4 are repeateduntil no new problems are found and all tasks wereconsidered in the final context. This ensures that alsothe adaptations are checked by management experts.

3.5 Step 5: Create ImperativeManagement Description Model

Create an Imperative Management Description Modelin the form of an executable process to perform themanagement tasks declared in the DMDM.

The verified and adapted Declarative Management De-scription Model resulting from the previous step de-scribes the tasks to be performed declaratively in anabstract manner—only what management tasks haveto be performed, but not how. Thus, the model is notexecutable as the technical realization is not described.Therefore, an executable process model that imple-ments the management tasks declared in the DMDMmust be created. As this process model describes howthe tasks have to be executed imperatively, we callthese management processes Imperative ManagementDescription Models (IMDM). An IMDM can be ex-ecuted using an appropriate process engine and de-scribes also the control flow and data handling betweenthe management tasks. The IMDM has to implementexactly the semantics of the management tasks de-scribed by the adapted Declarative Management De-scription Model resulting from the previous step.

3.6 Step 6: Execute ImperativeManagement Description Model

Execute the created Imperative Management Descrip-tion Model to manage the running application.

In the last step, the IMDM is executed to perform thedesired management tasks on the real running appli-cation. Therefore, a process engine is employed torun the process. As a result, the changes describedby the tasks are applied to the running application inconsideration of the context. Afterwards, the methodmay start from the beginning to execute further tasks.

4 VALIDATION

The presented method enables combining declar-ative management descriptions, which include all rel-evant context information to verify the managementtasks, and imperative processes, which are employedto actually perform the tasks on running applications.Thus, it combines two different types of ManagementDescription Models which enables benefiting fromadvantages of both worlds. Therefore, the presentedmethod provides a theoretic basis for enabling auto-mated context-aware application management. In thissection, we validate the proposed method by showinga fully automated practical implementation using ex-isting frameworks. We describe the realization of theprototype for all steps of the method in the following.

4.1 Formalizing Applications UsingEnterprise Topology Graphs

In Step 1, the application’s structure and runtime in-formation needs to be captured in a formal model. Weuse Enterprise Topology Graphs (ETG) (Binz et al.,2012) as model language as they are a common way tocapture such information formally. ETGs are directed,possibly acyclic, graphs that describe the application’sstructure as topology model that contains each compo-nent as typed node and each relationship as typed edgebetween the nodes. Runtime information of nodes andrelations are captured as properties of the respectiveelement. Thus, ETGs can be used to model the contextin which a management task is executed. As ETGssupport the XML-format, they are machine readable.Figure 2 shows the motivating scenario as ETG ex-ample, graphically rendered using the visual topologynotation “Vino4TOSCA” (Breitenbucher et al., 2012).Each component is depicted as rounded rectangle, re-lations as arrows between these rectangles, and run-time information as key-value properties. Element IDs

File: BA_Frontend.zip URL: 129.78.43.72:8080/BA

Frontend (PHP)

HttpPort: 8080 Username: Admin Password: w1j4vg!osb PHPModule: Installed

(ApacheHTTPServer)

SSHCredentials: [….] IP-Address: 129.78.43.72

(Ubuntu12.04VM)

User: MyAzureAccount Password: h94jfds!fg3

(WindowsAzure)

(hostedOn)

(SQLConnection)

Legend:

DBName: BA_DB DBUser: u4001 DBPassword: a7ju2vf!b

Database (PostgreSQLDB)

Port: 5432 User: MyAccount Password: a8u8u29uer8u234

(AmazonRDS)

Figure 2: ETG of the running application.

are undecorated text, element types are enclosed byparentheses. Binz et al. showed that ETGs of runningapplications can be discovered fully automatically us-ing the ETG Discovery Framework (Binz et al., 2013).Thus, the first step of formalizing the application to bemanaged can be automated by using this framework.

4.2 Automating DMDM Creation UsingAutomated Management Patterns

Capturing running application snapshots in such for-mal ETG models provides a structured means to de-scribe the context in which a management task is ex-ecuted. Therefore, to create the DMDM in the sec-ond step, we use the discovered ETG and annotatethe management tasks to be executed directly at theaffected components and relations of the ETG. In Bre-itenbucher et al. (Breitenbucher et al., 2013a), we in-troduced so-called Desired Application State Models,which provide exactly this type of model for describ-ing tasks to be executed declaratively in the context inwhich they have to be executed based on ETGs.

Figure 3 shows the Desired Application StateModel that describes our migration motivating sce-nario. The colored circles with the symbols inside rep-resent the management tasks to be executed in the formof so-called Management Annotations (Breitenbucheret al., 2013a). A Management Annotation describes atask to be performed in a declarative way: It definesonly the type of the task and possible configurationproperties, but not how to execute it. The green colored“Create-Annotations” with the star inside declare thatthe corresponding element it is attached to has to becreated, while the red colored “Destroy-Annotations”

(hostedOn)

(SQLConnection)

Legend:

File: BA_Frontend.zip URL: 129.78.43.72:8080/BA

Frontend (PHP)

HttpPort: 8080 Username: Admin Password: w1j4vg!osb PHPModule: Installed

(ApacheHTTPServer)

SSHCredentials: […] IP-Address: 129.78.43.72

(Ubuntu12.04VM)

User: MyAzureAccount Password: h94jfds!fg3

(WindowsAzure)

DBName: BA_DB DBUser: u4001 DBPassword: a7ju2vf!b

Database (PostgreSQLDB)

Port: 5432 User: MyAccount Password: a8u8u29uer8u234

(AmazonRDS)

File: BA_Frontend.zip URL:

Frontend (PHP)

HttpPort: 8080 Username: Admin Password: w1j4vg!osb PHPModule: Installed

(ApacheHTTPServer)

SSHCredentials: […] IP-Address:

(Ubuntu12.04VM)

User: MyAccount Password: a8u8u29uer8u234

(AmazonEC2)

Figure 3: Desired Application State Model resulting from applying the Automated Management Pattern to the discovered ETG.

with the “x” inside declare that the model element hasto be destroyed. Management Annotations can be alsobound declaratively to non-functional requirementsin the form of policies that must be fulfilled whenexecuting the task (Breitenbucher et al., 2013c).

Annotating management tasks to ETGs, i. e., creat-ing a DMDM, can be automated, too: Desired Appli-cation State Models can be created automatically byapplying so-called Automated Management Patternsto ETGs (Breitenbucher et al., 2013a). An AutomatedManagement Pattern captures management expertisethrough implementing a transformation that annotatesmanagement tasks in the form of Management An-notations fully automatically to an input ETG. Thistransformation attaches, configures, or removes nodes,relations, and Management Annotations. In addition,Automated Management Patterns can be configuredvia input parameters. For example, the Desired Ap-plication State Model shown in Figure 3 is the resultof applying the “Migrate PHP-based Application toAmazon Pattern”, which was configured to use Ama-zon’s IaaS offering EC2 for hosting the PHP frontend.The only manual step is selecting and configuring thepattern. Thus, Step 2 can be automated, too.

4.3 Context-Aware Task Analyzer

After the Desired Application State Model was createdautomatically by applying an Automated ManagementPattern, it has to be analyzed by experts in Step 3 andadapted if necessary in Step 4. As we aim at automat-ing the whole method realization, also these two steps

need to be automated. Therefore, we introduce the con-cept of Context-Aware Management Task Analyzers(CAMTA) that provides a means to capture context-aware expert management knowledge in a form thatenables a fully automated application to the DesiredApplication State Model resulting out of the previousstep. The notion of CAMTAs is detecting and correct-ing problems by analyzing the tasks in their contextand adapting the model if necessary fully automaticallywithout manual interaction. Therefore, a CAMTA con-sists of two parts: (i) An Annotated Topology Fragmentand a (ii) Transformation, similarly to Automated Man-agement Patterns. The Annotated Topology Fragmentis a small topology that specifies the management tasksin a certain context for which the CAMTA is able to(i) analyze correctness and (ii) may provide expertmanagement knowledge required to adapt the model ifnecessary. The fragment is used for matchmaking ofCAMTAs and Desired State Models: If all elements ina CAMTA’s fragment match elements in the model, theContext-Aware Management Task Analyzer is able toanalyze exactly that part. Thus, the Annotated Topol-ogy Fragment is used to select the CAMTAs that haveto be applied to analyze the DMDM in Step 3 fullyautomatically. For adapting the model in Step 4, eachCAMTA implements a context-aware transformationthat transforms the input Desired State Model fullyautomatically if necessary. Therefore, the transfor-mation checks if the tasks specified in the CAMTA’sTopology Fragment can be executed safely: If yes, thetransformation returns the unmodified model. If not,the transformation adds or configures components, re-

Resolving Missing Database Driver CAMTA

Transformation Annotated Topology Fragment

(ApacheHTTPServer)

(hostedOn)

(PostgreSQLDB) (PHP)

Figure 4: CAMTA that recognizes the problem of missingPostgreSQL database connector driver.

lationships, or tasks for correcting the Desired StateModel. Figure 4 shows a CAMTA that analyzes thetasks of establishing a SQL connection from a PHPapplication hosted on an Apache HTTP Server to aPostgreSQL database. The shown CAMTA is ableto analyze if establishing a SQL-Connection in thecontext of a PHP Application running on the ApacheHTTP Server to a PostgreSQL database is possible.This is expressed by its Topology Fragment on the left.The transformation shown on the right analyzes theDesired State Model and finds out that the PostgreSQLconnector driver is missing. Therefore, it adds the cor-responding elements and tasks to the model. Thus,based on two CAMTAs, the Desired State Model,which results from applying the automated migra-tion pattern in Step 2, gets adapted fully automati-cally for resolving the issues of the missing databaseconnector and Security Group configuration. There-fore, the respective CAMTAs insert two different Man-agement Annotations into the Desired State Model:(i) a “ConfigureSecurityGroup-Annotation” that is at-tached to the AmazonRDS node and an “InstallDriver-Annotation” attached to the Apache HTTP Servernode. The ConfigureSecurityGroup-Annotation con-figures the AmazonRDS instance in a way that thedatabase is accessible by the Apache HTTP Server,the InstallDriver-Annotation declares that the requiredconnector for PostgreSQL databases must be installed.

As Desired State Models typically specify multi-ple management tasks to be executed in the form ofManagement Annotations that need to be analyzed intheir context, multiple different CAMTAs are neededto check the correctness of the whole model. As theymay add or configure elements, all CAMTAs need tobe applied every time after one transformed the modelto ensure that all tasks are validated in the current con-text that may be changed by formerly applied CAM-TAs. As soon as input and output model do not changeanymore after applying all matching CAMTAs, Step4 is finished. The approach is similar to AutomatedManagement Patterns (Breitenbucher et al., 2013a)that also use transformations to modify models.

Create Ubuntu12.04VM on AmazonEC2

(AmazonEC2)

User: * Password: *

SSHCredentials: * Type: * …

(Ubuntu12.04VM)

(hostedOn)

Annotated Topology Fragment Workflow

P

Figure 5: Management Planlet that creates an Ubuntu12.04virtual machine on Amazon EC2.

4.4 Management Plan Generation

After the DMDM was analyzed and adapted for cor-rectness in Step 3, the resulting model is not executabledirectly as it describes the tasks to be performed onlydeclaratively, i. e., without implementation or controlflow: The Declarative Management Description Modelhas to be transformed into an executable ImperativeManagement Description Model in Step 5. There-fore, we employ the management framework presentedby Breitenbucher et al. (Breitenbucher et al., 2013a)that employs Management Planlets to translate De-sired Application State Models fully automatically intoexecutable BPEL workflows. Management Planletsprovide the low-level imperative management logicto execute the declarative Management Annotationsused in Desired Application State Models and supportdefining functional as well as non-functional require-ments (Breitenbucher et al., 2013c). They serve asgeneric management building blocks that can be or-chestrated to implement a higher-level managementtask. A Management Planlet consists of two parts:(i) Annotated Topology Fragment and (ii) a workflow.The fragment exposes the Planlet’s functionality and isused to find Planlets that are capable of executing thespecified management tasks in the specified context.For example, the Planlet shown in Figure 5 is capa-ble of executing the Create-Annotation attached to anUbuntu12.04VM node if this node has to be hostedon AmazonEC2. The Planlet’s executable workflowimplements exactly the management logic required tocreate this virtual machine on EC2. Based on thesefragments, different Planlets can be orchestrated to im-plement an overall management plan that performs allmanagement tasks defined in the Desired ApplicationState Model. Therefore, the framework employs a Plan

Management Workflow

Planlet Repository

Plan Generator

Adapted Desired Application State Model

c

x

Pattern Repository

Pattern Applier

Desired Application State Model

x

CAMTA Repository

CAMTA Applier

Enterprise Topology Graph

e

Figure 6: Conceptual Architecture of the method’s realization.

Generator that transforms Desired Application StateModels into executable management workflows. Thewhole method realization is shown in Figure 6: A dis-covered ETG is transformed into a Desired ApplicationState Model by applying an Automated ManagementPattern. This model is analyzed and possibly adaptedby several CAMTAs. The Plan Generator gets the re-sulting model as input, searches Planlets that are ableto execute the specified Management Annotations, andorchestrates the matching Planlets’ workflows to anoverall management workflow. This workflow imple-ments all management tasks declared by the DesiredApplication State Model and can be executed in Step6 to perform the tasks on the real running application.

4.5 Evaluation of the Realization

The introduced declarative model layer describingtasks in its formal context that encompasses all ap-plication components, their relations, and runtime in-formation enables experts to detect dependencies thatare not visible in traditional imperative managementprocesses such as workflows. The reason is that thesetraditional processes describe only logic for the di-rectly affected components, not the surrounding envi-ronment context: Details of the application structure,i. e., the context, are not contained in such process mod-els and can, thus, not be analyzed. However, especiallyworkflow technology and script-centric technologiessuch as Chef are well-established technologies usedin systems management due to the provided featuresand properties: Workflow technology provides fea-tures, such as recoverability and compensation mech-anisms, that enable correct and complete executionof long running processes, which is often a major re-quirement (Leymann and Roller, 2000). On the otherside, the script-centric DevOps communities providea lot of templates and implementations that can beused for configuration management without furthermodifications. The method enables using these tech-

nologies for the actual execution of the managementtasks in the form of IMDMs. Thus, it enables com-bining both types of management description modelsto support both consideration of context and profitingfrom features provided by common technologies.

The presented realization is limited in terms ofcompleteness: Management tasks in a Desired Appli-cation State Model are analyzed and possibly adaptedonly if there are CAMTAs that provide the requiredknowledge for analyzing and adapting the tasks in theactual context. The approach could be extended bymarking all verified management tasks, i. e., all Man-agement Annotations that were considered by one ormore CAMTAs. In addition, a description of the taskanalysis could be added by CAMTAs to provide in-formation about the analyzed issues and determinedproblems. This may help users to understand the per-formed analysis and enables drawing their attention tothe tasks that were not considered by the system. Thesetasks could be then analyzed manually by experts be-fore generating the final management workflow.

5 RELATED WORK

Context-aware systems adapt their functionalityand behaviour using context information about the en-vironment. An often used definition for context wasgiven by Dey (Dey et al., 2000): “Context is any infor-mation that can be used to characterize the situationof an entity, where an entity can be a person, place,physical or computational object”. An important typeof context information, which is often neglected, is thestate and structure of an application to be managed. Inthis paper, we use this type of context information toverify, configure, and execute management tasks onapplications and their infrastructure. The automatedrealization of the presented management method pro-vides, therefore, the basis to implement Context-awareCloud Application Management Systems.

To model and manage context information, manyframeworks have been developed in the past years.There are simple, widget-like frameworks for sensorinformation such as the Context Toolkit (Dey et al.,2001) and systems that support smart environmentslike Aura (Judd and Steenkiste, 2003) or Gaia (Romanand Campbell, 2000). Different types of developmentframeworks, e. g., the framework of Henricksen andIndulska (Henricksen and Indulska, 2004), and con-text management platforms, e. g., the Nexus Platform(Großmann et al., 2005), were developed that aim atefficient provisioning of context information within aglobal scope. These frameworks use Context Modelsas an abstraction layer between applications and thetechnical infrastructure that gathers the context data.However, there is no framework that manages contextinformation for application management in the formof topology models. The Declarative ManagementDescription Model introduced in this paper provides akind of Context Model that (i) enables to capture theenvironment in which management tasks are executedand (ii) the management tasks themselves describedin a declarative fashion. The context is captured in adomain-specific data structure in the form of ETGs.Furthermore, no sensors integration has to be achievedbecause the context is detected on the fly using theETG Discovery Framework (Binz et al., 2013). Thus,the context is always up to date and does not have tobe stored or managed using additional tooling.

There are several approaches that enable de-scribing application topologies including runtime in-formation and dependencies. Scheibenberger andPansa (Scheibenberger and Pansa, 2008) present ageneric meta model to describe resource dependen-cies among IT infrastructure components. They sep-arate the static view, which captures functional andstructural aspects, from the dynamic operational view,which captures runtime information. In contrast tothe employed concept of ETGs in the validation, theirapproach enables to model dependencies between com-ponent properties. The method’s realization may be ex-tended to capture also such fine-grained dependenciesif necessary that may help experts to analyze possibleimpacts of a certain management task. The CommonInformation Model (CIM) (Distributed ManagementTask Force, 2010) is a standard that provides an ex-tensible, object-oriented data model used to captureinformation about different parts of an enterprise. Italso provides a specification to describe applicationstructures including dependencies. However, all theseworks may be used to formalize the application struc-ture, dependencies, and runtime information, but theyprovide no means to model also the management tasksto be executed as required to implement a DMDM.

There are several frameworks that employ declara-tive descriptions to generate workflows such as Eilamet al. (Eilam et al., 2011), Maghraoui et al. (Maghraouiet al., 2006), and Keller et al. (Keller et al., 2004). Thefirst two focus mainly on provisioning of applicationswhereas the third also considers application manage-ment. In general, the proposed method can be appliedto approaches and frameworks that transform declara-tive descriptions into imperative processes. However,it must be ensured that the declarative descriptions(i) provide the whole context and (ii) that the man-agement tasks to be executed are described by thismodel somehow. In a former work (Breitenbucheret al., 2014), we showed how declarative provisioningdescriptions can be transformed automatically into im-perative provisioning workflows based on the TOSCAstandard (OASIS, 2013). The application to be pro-visioned is described as a topology, which models allcomponents and relations of the application. As thetasks to be executed are clear (create each applicationcomponent and instantiate the relations between thecomponents) and the whole context of the provisioningis provided by this model in the form of the applicationtopology, the presented method can be applied to thisstandards-based provisioning approach, too.

6 CONCLUSIONS

In this paper, we introduced an abstract Context-Aware Application Management Method that enablesapplying context-aware management expertise to run-ning Cloud applications. We showed that separatingmodels for context-aware analysis and managementexecution provides a powerful means to benefit fromadvantages of both worlds. Therefore, we employedabstract Declarative Management Description Modelsfor describing the context as well as the managementtasks to be executed themselves that are transformedinto Imperative Management Description Models. Thepresented method is validated by an automated proto-typical realization for Cloud Application Managementusing existing frameworks and technologies. In future,we plan to integrate non-functional requirements intothe method and its realization and to apply both to theOASIS standard TOSCA.

ACKNOWLEDGEMENTS

This work was partially funded by the BMWi projectCloudCycle (01MD11023).

REFERENCES

Binz, T., Breitenbucher, U., Kopp, O., and Leymann, F.(2013). Automated Discovery and Maintenance ofEnterprise Topology Graphs. In SOCA, pages 126–134.IEEE.

Binz, T., Fehling, C., Leymann, F., Nowak, A., and Schumm,D. (2012). Formalizing the Cloud through EnterpriseTopology Graphs. In CLOUD, pages 742–749. IEEE.

Breitenbucher, U., Binz, T., Kepes, K., Kopp, O., Leymann,F., and Wettinger, J. (2014). Combining Declarativeand Imperative Cloud Application Provisioning basedon TOSCA. In IC2E. IEEE.

Breitenbucher, U., Binz, T., Kopp, O., and Leymann, F.(2013a). Pattern-based Runtime Management of Com-posite Cloud Applications. In CLOSER. SciTePressDigital Library.

Breitenbucher, U., Binz, T., Kopp, O., Leymann, F., andWettinger, J. (2013b). Integrated cloud application pro-visioning: Interconnecting service-centric and script-centric management technologies. In CoopIS, pages130–148. Springer.

Breitenbucher, U., Binz, T., Kopp, O., Leymann, F., andWieland, M. (2013c). Policy-Aware Provisioning ofCloud Applications. In SECURWARE, pages 86–95.Xpert Publishing Services.

Breitenbucher, U. et al. (2012). Vino4TOSCA: A VisualNotation for Application Topologies based on TOSCA.In CoopIS, pages 416–424. Springer.

Brown, A. B. and Patterson, D. A. (2001). To err is human.In EASY, page 5.

Dey, A. K., Abowd, G., and Salber, D. (2000). A context-based infrastructure for smart environments. In Man-aging Interactions in Smart Environments, pages 114–128. Springer.

Dey, A. K., Abowd, G. D., and Salber, D. (2001). A con-ceptual framework and a toolkit for supporting therapid prototyping of context-aware applications. Hum.-Comput. Interact., 16:97–166.

Distributed Management Task Force (2010). Common Infor-mation Model.

Eilam, T. et al. (2011). Pattern-based composite applica-tion deployment. In Integrated Network Management.IEEE.

Fehling, C., Leymann, F., Rutschlin, J., and Schumm, D.(2012). Pattern-based development and managementof cloud applications. Future Internet, 4:110–141.

Großmann, M., Bauer, M., Honle, N., Kappeler, U.-P., Nick-las, D., and Schwarz, T. (2005). Efficiently ManagingContext Information for Large-Scale Scenarios. InPerCom. IEEE.

Henricksen, K. and Indulska, J. (2004). A Software Engi-neering Framework for Context-Aware Pervasive Com-puting. In PerCom. IEEE.

Judd, G. and Steenkiste, P. (2003). Providing contextualinformation to pervasive computing applications. InPerCom. IEEE.

Keller, A., Hellerstein, J. L., Wolf, J. L., Wu, K.-L., andKrishnan, V. (2004). The champs system: changemanagement with planning and scheduling. In NOMS,pages 395–408. IEEE.

Leonhardt, S. (2013). A generic artifact-driven approach forprovisioning, configuring, and managing infrastructureresources in the cloud. Diploma thesis, University ofStuttgart, Germany.

Leymann, F. (2009). Cloud Computing: The Next Revo-lution in IT. In The Photogrammetric Record, pages3–12.

Leymann, F. and Roller, D. (2000). Production workflow:concepts and techniques. Prentice Hall PTR.

Maghraoui, K. E. et al. (2006). Model driven provisioning:Bridging the gap between declarative object modelsand procedural provisioning tools. In Middleware,pages 404–423. Springer.

Malone, T., Blokdijk, G., and Wedemeyer, M. (2008). ITILV3 Foundation Complete Certification Kit. Art of Ser-vice Pty Limited.

Nelson-Smith, S. (2013). Test-Driven Infrastructure withChef. O’Reilly Media, Inc.

OASIS (2007). Web services business process executionlanguage (WS-BPEL) version 2.0.

OASIS (2013). Topology and Orchestration Specificationfor Cloud Applications Version 1.0.

OMG (2011). Business Process Model and Notation(BPMN), Version 2.0.

Oppenheimer, D., Ganapathi, A., and Patterson, D. A. (2003).Why do internet services fail, and what can be doneabout it? In USITS. USENIX Association.

Roman, M. and Campbell, R. H. (2000). Gaia: Enablingactive spaces. In SIGOPS, pages 229–234. ACM.

Scheibenberger, K. and Pansa, I. (2008). Modelling depen-dencies of it infrastructure elements. In BDIM, pages112–113. IEEE.