Context-aware Cloud Application Management 2014/CLOSER... · Java. Especially the more and more emerging script-centric conﬁguration management technologies such as Chef (Nelson-Smith,

Context-aware Cloud Application Management

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

fbreitenbuecher, [email protected]

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 diversityand heterogeneity of employed technologies, even small management tasks on single components may com-promise the whole application functionality for reasons that are neither expected nor obvious to non-experts.In this paper, we tackle these issues by introducing a method that enables detecting and correcting unintendedeffects of management tasks in advance by analyzing the context in which tasks are executed. We validate themethod practically and show how context-aware expert management knowledge can be applied fully automat-ically to running Cloud applications.

1 INTRODUCTION

In recent years, Cloud Computing gained a lot of at-tention due to its economical and technical benefits.Especially properties such as pay-on-demand com-puting, self-service, and elasticity enable enterprisesto outsource IT (Leymann, 2009). These propertiesare key success factors for both Cloud providers aswell as customers. To exploit these properties reli-ably for their offerings, Cloud providers have to au-tomate their internal processes for application provi-sioning, configuration, and management. Therefore, alot of tools, methods, and technologies have been de-veloped in the past years: Script-centric DevOps com-munities support automated configuration manage-ment, guidelines such as the Information TechnologyInfrastructure Library (ITIL) (Malone et al., 2008)help applying best practices to IT service manage-ment, and standards such as TOSCA (OASIS, 2013)enable application developers to describe applicationsand their management in a portable way—to namea few examples. However, automating managementtasks on complex Cloud applications becomes a moreand more difficult challenge: The increasing numberand diversity of employed Cloud services on variouslayers offered by different Cloud providers leads toa higher risk of unexpected side effects when theyare combined with each other or integrated with tradi-tional software components and middleware systems.Additional complexity arises from the heterogeneity

of management technologies: Cloud providers, mid-dleware systems, and software components often pro-vide proprietary management APIs, security mecha-nisms, and data formats (Breitenbucher et al., 2013b).Thus, if a task affects multiple different parts of an ap-plication, also the management technologies of theseparts may need to be integrated. This requires (i) adeep technical insight in each part and managementtechnology as well as (ii) an overall understanding ofthe whole system and possible impacts to avoid errors.In these scenarios, often only experts of the respectivetechnology are able to execute management tasks cor-rectly. However, also experts reach their limits whena management task has to be executed on a complexapplication whose exact structure and runtime infor-mation are not documented: Unknown relations anddependencies between components that directly influ-ence each other’s functionality lead to a serious man-agement challenge. Even if only a small operation hasto be executed on a single component, its impact onother components is not predictable seriously if theapplication’s structure is not known exactly. Thus,if the context, in which a management task is ex-ecuted, is not known, understood, and considered,there is a high risk of unexpected side effects thatmay compromise the application’s functionality. Inaddition, as executing management task manually isslow, costly, and error prone, Cloud application man-agement must be automated to enable Cloud proper-ties (Fehling et al., 2012; Oppenheimer et al., 2003).

499

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) considerthe context in which tasks are executed, and (iii) auto-mate management processes to avoid manual errors.

In this paper, we tackle these issues. We presentan approach that enables applying expert manage-ment knowledge for tasks in a certain context auto-matically to running Cloud applications. Therefore,we introduce an abstract (i) Context-Aware Applica-tion Management Method and (ii) present a fully au-tomated realization of this method for Cloud Comput-ing to validate its practical feasibility. The method in-troduces Declarative Management Description Mod-els (DMDM) to describe management tasks declar-atively including their context in a formal model.This enables experts to detect unintended impacts andside effects of management tasks through analyzingthem in the context in which they are executed. Weshow that an individual context analysis is requiredfor many management tasks on Cloud applicationsdue to the heterogeneous nature of the involved com-ponents and management technologies—which is notpossible having traditional imperative models such asworkflows or scripts as these models describe only thetask-specific information but not the context in whichthey are executed. The presented automated realiza-tion of the method for Cloud application managementvalidates the method’s practical feasibility. It enablesCloud providers to offer a variety of different Cloudapplications consisting of heterogeneous componentswithout the need to employ or educate specializedexperts that have the required technical managementknowledge.

The remainder of this paper is structured as fol-lows: In Section 2, we describe a motivating scenarioto explain the method, which is introduced in Sec-tion 3. Section 4 presents the automated realizationof the method to validate its practical feasibility forCloud application management. In Section 5 we givean overview on related work. Section 6 concludes thepaper and gives an outlook on future work.

2 MOTIVATION

In this section, we describe the problem tackled byour approach in detail and introduce a motivating sce-nario that is used throughout the paper to explain thepresented 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 companyis often not possible (Fehling et al., 2012). The focusof this paper lies, therefore, on the management ofComplex Composite Cloud Applications, which con-sist of multiple heterogeneous Cloud services, soft-ware components, and middleware systems of differ-ent vendors and 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—whichare most often proprietary implementations providingheterogeneous management interfaces (Leonhardt,2013). As a consequence, human-induced failuresaccount for a significant number of outages as hu-man errors accompany even the simplest system op-eration and management tasks (Brown and Patter-son, 2001). The management flexibility recently in-troduced by Cloud Computing has additionally in-creased this effect as management tasks, such as theprovisioning of new virtual machines, are literally atthe systems manager’s fingertips and often handledcompletely via proprietary management interfaces of-fered by Cloud providers (Fehling et al., 2012). Dueto this management evolution, human errors are morelikely to occur since the physical infrastructure andthereon deployed software systems are often virtual-ized and, therefore, obfuscating the actual structure ofan application. Thus, it becomes more and more dif-ficult to consider the context, in which managementtasks are executed, correctly as application structures,system boundaries, and dependencies are becomingincreasingly blurred by the Cloud. In addition, dueto the lack of interoperability between Cloud servicesof different providers and traditional software com-ponents, most often complex configuration manage-ment is needed to integrate heterogeneous systems.As a result, executing management tasks which affectmultiple parts of an application at once requires spe-cial management expertise. These problems impedeautomating Cloud application management, which isa major requirement for efficient use of Cloud re-sources and to avoid manual human errors (Fehlinget al., 2012; Oppenheimer et al., 2003). Therefore,we need a means to capture and apply context-awaremanagement expertise fully automatically to runningCloud applications.

CLOSER�2014�-�4th�International�Conference�on�Cloud�Computing�and�Services�Science

500

2.2 Management Automation

To automate application management, the execu-tion of management tasks is often described imper-atively using executable processes implemented asworkflows (Leymann and Roller, 2000) in languagessuch as BPEL (OASIS, 2007) or BPMN (OMG,2011), scripts such as bash, or programs imple-mented in a computer programming language such asJava. Especially the more and more emerging script-centric configuration management technologies suchas Chef (Nelson-Smith, 2013) are prime examplesfor this kind of imperative management descriptions.However, if an application is crucial to the businessof an enterprise, errors that possibly result in sys-tem downtime are not acceptable. Therefore, beforeexecuting such management processes, they must beverified by experts to ensure correctness. Unfortu-nately, one of the most important problems of thisapproach is that the context, in which the manage-ment tasks are executed, is not explicitly describedand, thus, not visible in such processes. As a result,management processes cannot be analyzed by expertsin consideration of the management tasks’ context asonly operation calls, service invocations, or script ex-ecutions on the directly affected components are de-scribed, but not the surrounding environment: Expertssee only the directly affected part of the application,not the whole application structure. Thus, other ap-plication components that may be affected indirectly,too, cannot be considered in this analysis. For exam-ple, if the database of a Web-based application shallbe replaced by a database from a different vendor,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, it

is currently distributed over two Clouds: The PHPfrontend is hosted on Microsoft’s public Cloud of-fering “Windows Azure”1, the PostgreSQL databaseon Amazon’s PaaS offering “Relational Database Ser-vice (RDS)”2, which enables hosting databases di-rectly as a service. The PHP frontend runs on anApache HTTP Server (including the PHP-module)which is installed on an Ubuntu Linux operating sys-tem that runs in a virtual machine hosted on Azure.The management task that has to be executed is mi-grating the PHP frontend to Amazon’s IaaS offering“Elastic Compute Cloud (EC2)”3 in order to reducethe number of employed Cloud providers. This mi-gration results in two issues that compromise the ap-plication’s functionality if they are not considered byexperts having the knowledge to recognize the follow-ing two problems in advance: (i) missing databasedriver and (ii) missing configuration of the databaseservice. To migrate the PHP frontend, we have tocreate a new virtual machine on Amazon EC2, in-stall the Apache HTTP Server and the PHP-module,and deploy the corresponding PHP files on it. Thisworks without further configuration issues. However,connecting the PHP application to the database isnot as easy as it seems to be: Simply defining thedatabase configuration of the PHP frontend by set-ting the database’s endpoint, username, and passwordis not sufficient. Here, a technical detail of the un-derlying infrastructure needs to be considered: ThePHP-module of the Apache HTTP Server needs dif-ferent database drivers to connect to different types ofdatabases. Thus, if the PostgreSQL driver gets not in-stalled explicitly on the server, the Moodle PHP fron-tend is not able to connect to the database. However,this is not easy to recognize as applications often em-ploy MySQL databases whose drivers are typicallyinstalled together with the PHP-module. Thus, in-stalling 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 are perdefault not accessible from external components. Toallow connections, a so-called “Security Group” mustbe defined to configure the firewall. This group spec-ifies the IP-addresses which are allowed to connect tothe database. Both issues result in breaking the ap-plication’s functionality as the frontend cannot con-nect to the database. The reason for both problemslies in ignoring the context in which the tasks are exe-cuted: First, if an application shall connect to a certaintype of database, the runtime environment hosting the

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

Context-aware�Cloud�Application�Management

501

application must support connecting to this kind ofdatabase. It is not enough to simply set the configu-ration as the underlying infrastructure, i. e., the con-text, needs to be considered, too. Second, accessing adatabase hosted on Amazon RDS requires also morethan simply writing endpoint information into a con-figuration file as also the firewall of the service has tobe configured. Thus, also for this task, the context inthe 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 con-text is not described. In addition, if administratorsexecute this migration manually, they require a lot oftechnical expertise and background information aboutthe different APIs and employed technologies. Thus,we need a means to (i) capture expert managementknowledge for a certain context and (ii) make it appli-cable fully automatically in order to help administra-tors avoiding unintended 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)we capture all runtime information and the structureof the application to be managed in a formal modelwhich is extended in the second step (2) by declaringtasks on components and relations. In the third step,(3) experts analyze this model for unintended side ef-fects and (4) adapt the model afterwards if necessaryto resolve the found problems. In the fifth step, (5)this declarative model is translated into an imperativeprocess model that is executed in the last step (6) toperform the tasks on the running application. We ex-plain each step in the following subsections and start

Context-Aware Application Management

Method

1. Capture Application as Formal Model

2. Create Declarative

Management Description

Model

3. Analyze Declarative


Model

4. Adapt Declarative


Model

5. Create Imperative


Model

6. Execute Imperative


Model

Figure 1: Context-Aware Application ManagementMethod.

each description with a short summary of the step initalic text to provide a compact overview that is de-tailed afterwards.

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 describedas a formal model. This model captures the ap-plication structure and its state, i. e., all compo-nents such as Web servers, virtual machines, orinstalled applications, the relations between them,e. g., database connections, and their runtime infor-mation. The semantics of components and rela-tions (we call both model elements in the follow-ing) are described using types, e. g., a componentmay be of type “ApacheHTTPServer”, a relation-ship of type “SQLConnection”. To enable a pre-cise definition of the model elements, types can beinherited: the “ApacheHTTPServer” type is a sub-type of “HTTPServer”. Runtime information aredescribed as model element properties, e. g., the“ApacheHTTPServer” has properties “IP-Address”and “Port” that specify the server’s endpoint. Theproperty schema is defined by the type of the modelelement. This formalization of the running applica-


502

tion provides a detailed, structured, and machine read-able means to document a current snapshot of the ap-plication structure and all runtime information.

3.2 Step 2: Create DeclarativeManagement Description Model

Create a Declarative Management DescriptionModel that declaratively describes the managementtasks to be 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 notexecutable as it describes only what has to be done,but not how—all technical details are missing. Forexample, a DMDM may declare a “Create” task ona relation of type “SQLConnection” between a PHPapplication and an SQL database, which means thatthe connection has to be established. However, itprovides neither technical implementation details norspecifies the control flow between multiple differenttasks.

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 the ap-plication that are possibly affected. In the third step,management tasks are analyzed in their context by ex-perts of different domains to detect unexpected im-pacts leading to unintended side effects. DMDMs en-able cooperation between different experts and sepa-rate concerns based on a uniform, structured, and for-mal model: Experts on the “ApacheHTTPServer” areable to detect that the installation of a certain databaseconnector is required, experts on the Amazon Cloudare able to configure the Security Group in order toallow connections from the external PHP frontend of

the application. Thus, DMDMs can be analyzed bymultiple experts of different domains in a cooperativemanner.

3.4 Step 4: Adapt DeclarativeManagement Description Model

Adapt the analyzed Declarative Management De-scription Model if necessary to solve the analyzedproblems.

After the expert analysis, found problems have to beresolved in order to achieve the desired managementgoals. Therefore, the DMDM is adapted in this stepby the respective experts to enable correct executionof the management tasks. Therefore, components, re-lations, and tasks of the DMDM may be added or re-configured. For example, the missing database con-nector found in the analysis of the previous step isresolved by adding the task to install the required con-nector on the Web Server. Thus, each task was veri-fied in its respective context in the previous step andgets corrected if necessary in this step. However, iftasks are added or reconfigured, all tasks have to beanalyzed again for correctness as the context changedby this adaptation. This may lead to new problemsand unintended side effects on other components orrelations that have to be found. Therefore, Step 3 andStep 4 are repeated until no new problems are foundand all tasks were considered in the final context. Thisensures that also the adaptations are checked by man-agement experts.

3.5 Step 5: Create ImperativeManagement Description Model

Create an Imperative Management DescriptionModel in the form of an executable process to per-form the management tasks declared in the DMDM.

The verified and adapted Declarative ManagementDescription Model resulting from the previous stepdescribes the tasks to be performed declaratively inan abstract manner—only what management taskshave to be performed, but not how. Thus, the modelis not executable as the technical realization is notdescribed. Therefore, an executable process modelthat implements the management tasks declared inthe DMDM must be created. As this process modeldescribes how the tasks have to be executed imper-atively, we call these management processes Imper-ative Management Description Models (IMDM). AnIMDM can be executed using an appropriate processengine and describes also the control flow and data


503

handling between the management tasks. The IMDMhas to implement exactly the semantics of the man-agement tasks described by the adapted DeclarativeManagement Description Model resulting from theprevious step.

3.6 Step 6: Execute ImperativeManagement Description Model

Execute the created Imperative Management De-scription 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 declara-tive 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 wayto capture such information formally. ETGs are di-rected, possibly acyclic, graphs that describe the ap-plication’s structure as topology model that containseach component as typed node and each relationshipas typed edge between the nodes. Runtime informa-tion of nodes and relations are captured as propertiesof the respective element. Thus, ETGs can be usedto model the context in which a management task is

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.

executed. As ETGs support the XML-format, theyare machine readable. Figure 2 shows the motivatingscenario as ETG example, graphically rendered usingthe visual topology notation “Vino4TOSCA” (Bre-itenbucher et al., 2012). Each component is de-picted as rounded rectangle, relations as arrows be-tween these rectangles, and runtime information askey-value properties. Element IDs are undecoratedtext, element types are enclosed by parentheses. Binzet al. showed that ETGs of running applications canbe discovered fully automatically using the ETG Dis-covery Framework (Binz et al., 2013). Thus, the firststep of formalizing the application to be managed canbe 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 insiderepresent the management tasks to be executed in the


504

(hostedOn)

(SQLConnection)

Legend:

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

Frontend (PHP)


(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)


(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 discoveredETG.

form of so-called Management Annotations (Breit-enbucher et al., 2013a). A Management Annotationdescribes a task to be performed in a declarative way:It defines only the type of the task and possible con-figuration properties, but not how to execute it. Thegreen colored “Create-Annotations” with the star in-side declare that the corresponding element it is at-tached to has to be created, while the red colored“Destroy-Annotations” with the “x” inside declarethat the model element has to be destroyed. Manage-ment Annotations can be also bound declaratively tonon-functional requirements in the form of policiesthat must be fulfilled when executing the task (Breit-enbucher et al., 2013c).

Annotating management tasks to ETGs, i. e., cre-ating a DMDM, can be automated, too: Desired Ap-plication State Models can be created automaticallyby applying so-called Automated Management Pat-terns to ETGs (Breitenbucher et al., 2013a). An Au-tomated Management Pattern captures managementexpertise through implementing a transformation thatannotates management tasks in the form of Man-agement Annotations fully automatically to an in-put ETG. This transformation attaches, configures, orremoves nodes, relations, and Management Annota-tions. In addition, Automated Management Patternscan be configured via input parameters. For example,the Desired Application State Model shown in Fig-ure 3 is the result of applying the “Migrate PHP-basedApplication to Amazon Pattern”, which was config-ured to use Amazon’s IaaS offering EC2 for hosting

the PHP frontend. The only manual step is selectingand configuring the pattern. Thus, Step 2 can be au-tomated, too.

4.3 Context-aware Task Analyzer

After the Desired Application State Model was cre-ated automatically by applying an Automated Man-agement Pattern, it has to be analyzed by experts inStep 3 and adapted if necessary in Step 4. As weaim at automating the whole method realization, alsothese two steps need to be automated. Therefore, weintroduce the concept of Context-Aware ManagementTask Analyzers (CAMTA) that provides a means tocapture context-aware expert management knowledgein a form that enables a fully automated application tothe Desired Application State Model resulting out ofthe previous step. The notion of CAMTAs is detect-ing and correcting problems by analyzing the tasks intheir context and adapting the model if necessary fullyautomatically without manual interaction. Therefore,a CAMTA consists of two parts: (i) An AnnotatedTopology Fragment and a (ii) Transformation, simi-larly to Automated Management Patterns. The An-notated Topology Fragment is a small topology thatspecifies the management tasks in a certain contextfor which the CAMTA is able to (i) analyze correct-ness and (ii) may provide expert management knowl-edge required to adapt the model if necessary. Thefragment is used for matchmaking of CAMTAs andDesired State Models: If all elements in a CAMTA’s


505

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.

fragment match elements in the model, the Context-Aware Management Task Analyzer is able to analyzeexactly that part. Thus, the Annotated Topology Frag-ment is used to select the CAMTAs that have to beapplied to analyze the DMDM in Step 3 fully auto-matically. 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-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 theleft. The transformation shown on the right ana-lyzes the Desired State Model and finds out that thePostgreSQL connector driver is missing. Therefore,it adds the corresponding elements and tasks to themodel. Thus, based on two CAMTAs, the DesiredState Model, which results from applying the auto-mated migration pattern in Step 2, gets adapted fullyautomatically for resolving the issues of the missingdatabase connector and Security Group configuration.Therefore, the respective CAMTAs insert two differ-ent Management Annotations into the Desired StateModel: (i) a “ConfigureSecurityGroup-Annotation”that is attached to the AmazonRDS node and an“InstallDriver-Annotation” attached to the ApacheHTTP Server node. The ConfigureSecurityGroup-Annotation configures the AmazonRDS instance ina way that the database is accessible by the ApacheHTTP Server, the InstallDriver-Annotation declaresthat the required connector for PostgreSQL databasesmust be installed.

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.

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 needto be applied every time after one transformed themodel to ensure that all tasks are validated in the cur-rent context that may be changed by formerly appliedCAMTAs. As soon as input and output model do notchange anymore after applying all matching CAM-TAs, Step 4 is finished. The approach is similar to Au-tomated Management Patterns (Breitenbucher et al.,2013a) that also use transformations to modify mod-els.

4.4 Management Plan Generation

After the DMDM was analyzed and adapted for cor-rectness in Step 3, the resulting model is not exe-cutable directly as it describes the tasks to be per-formed only declaratively, i. e., without implementa-tion or control flow: The Declarative ManagementDescription Model has to be transformed into an ex-ecutable Imperative Management Description Modelin Step 5. Therefore, we employ the managementframework presented by Breitenbucher et al. (Bre-itenbucher et al., 2013a) that employs ManagementPlanlets to translate Desired Application State Mod-els fully automatically into executable BPEL work-flows. Management Planlets provide the low-levelimperative management logic to execute the declar-ative Management Annotations used in Desired Ap-plication State Models and support defining func-tional as well as non-functional requirements (Breit-enbucher et al., 2013c). They serve as generic man-


506

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.

agement building blocks that can be orchestrated toimplement a higher-level management task. A Man-agement Planlet consists of two parts: (i) AnnotatedTopology Fragment and (ii) a workflow. The frag-ment exposes the Planlet’s functionality and is usedto find Planlets that are capable of executing the spec-ified management tasks in the specified context. Forexample, the Planlet shown in Figure 5 is capableof 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 toimplement an overall management plan that performsall management tasks defined in the Desired Applica-tion State Model. Therefore, the framework employsa Plan Generator that transforms Desired ApplicationState Models into executable management workflows.The whole method realization is shown in Figure 6: Adiscovered ETG is transformed into a Desired Appli-cation State Model by applying an Automated Man-agement Pattern. This model is analyzed and possi-bly adapted by several CAMTAs. The Plan Genera-tor gets the resulting model as input, searches Plan-lets that are able to execute the specified ManagementAnnotations, and orchestrates the matching Planlets’workflows to an overall management workflow. Thisworkflow implements all management tasks declaredby the Desired Application State Model and can beexecuted in Step 6 to perform the tasks on the realrunning 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 these

traditional 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 processmodels and can, thus, not be analyzed. However, es-pecially workflow technology and script-centric tech-nologies such as Chef are well-established technolo-gies used in systems management due to the providedfeatures and properties: Workflow technology pro-vides features, such as recoverability and compensa-tion mechanisms, that enable correct and completeexecution of long running processes, which is oftena major requirement (Leymann and Roller, 2000). Onthe other side, the script-centric DevOps communi-ties provide a lot of templates and implementationsthat can be used for configuration management with-out further modifications. The method enables us-ing these technologies for the actual execution of themanagement tasks in the form of IMDMs. Thus,it enables combining both types of management de-scription models to support both consideration of con-text and profiting from features provided by commontechnologies.

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 attentionto the tasks that were not considered by the system.These tasks could be then analyzed manually by ex-perts before generating the final management work-flow.


507

5 RELATED WORK

Context-aware systems adapt their functionality andbehaviour using context information about the envi-ronment. An often used definition for context wasgiven by Dey (Dey et al., 2000): “Context is any in-formation that can be used to characterize the situ-ation of an entity, where an entity can be a person,place, physical or computational object”. An impor-tant type of context information, which is often ne-glected, is the state and structure of an application tobe managed. In this paper, we use this type of contextinformation to verify, configure, and execute manage-ment tasks on applications and their infrastructure.The automated realization of the presented manage-ment method provides, therefore, the basis to imple-ment Context-aware Cloud Application ManagementSystems.

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 providesa kind of Context Model that (i) enables to capturethe environment in which management tasks are ex-ecuted and (ii) the management tasks themselves de-scribed in a declarative fashion. The context is cap-tured in a domain-specific data structure in the formof ETGs. Furthermore, no sensors integration has tobe achieved because the context is detected on thefly using the ETG Discovery Framework (Binz et al.,2013). Thus, the context is always up to date anddoes not have to be stored or managed using addi-tional 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 to theemployed concept of ETGs in the validation, their ap-proach enables to model dependencies between com-ponent properties. The method’s realization may beextended to capture also such fine-grained depen-dencies if necessary that may help experts to ana-lyze possible impacts of a certain management task.The Common Information Model (CIM) (DistributedManagement Task Force, 2010) is a standard that pro-vides an extensible, object-oriented data model usedto capture information about different parts of an en-terprise. It also provides a specification to describeapplication structures including dependencies. How-ever, all these works may be used to formalize theapplication structure, dependencies, and runtime in-formation, but they provide no means to model alsothe management tasks to be executed as required toimplement a DMDM.

There are several frameworks that employ declar-ative descriptions to generate workflows such asEilam et al. (Eilam et al., 2011), Maghraoui etal. (Maghraoui et al., 2006), and Keller et al. (Kelleret al., 2004). The first two focus mainly on provi-sioning of applications whereas the third also consid-ers application management. In general, the proposedmethod can be applied to approaches and frameworksthat transform declarative descriptions into impera-tive processes. However, it must be ensured that thedeclarative descriptions (i) provide the whole contextand (ii) that the management tasks to be executedare described by this model somehow. In a formerwork (Breitenbucher et al., 2014), we showed howdeclarative provisioning descriptions can be trans-formed automatically into imperative provisioningworkflows based on the TOSCA standard (OASIS,2013). The application to be provisioned is describedas a topology, which models all components and re-lations of the application. As the tasks to be executedare clear (create each application component and in-stantiate the relations between the components) andthe whole context of the provisioning is provided bythis model in the form of the application topology,the presented method can be applied to this standards-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 separat-


508

ing models for context-aware analysis and manage-ment execution provides a powerful means to ben-efit from advantages of both worlds. Therefore, weemployed abstract Declarative Management Descrip-tion Models for describing the context as well as themanagement tasks to be executed themselves that aretransformed into Imperative Management DescriptionModels. The presented method is validated by anautomated prototypical realization for Cloud Appli-cation Management using existing frameworks andtechnologies. In future, we plan to integrate non-functional requirements into the method and its re-alization and to apply both to the OASIS standardTOSCA.

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., andSchumm, D. (2012). Formalizing the Cloud throughEnterprise Topology 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 Managementof Composite Cloud Applications. In CLOSER.SciTePress Digital Library.

Breitenbucher, U., Binz, T., Kopp, O., Leymann, F., andWettinger, J. (2013b). Integrated cloud applica-tion provisioning: Interconnecting service-centric andscript-centric management technologies. In CoopIS,pages 130–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 Vi-sual Notation for Application Topologies based onTOSCA. 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). Aconceptual framework and a toolkit for supportingthe rapid prototyping of context-aware applications.Hum.-Comput. Interact., 16:97–166.

Distributed Management Task Force (2010). Common In-formation 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.,Nicklas, D., and Schwarz, T. (2005). Efficiently Man-aging Context Information for Large-Scale Scenarios.In PerCom. IEEE.

Henricksen, K. and Indulska, J. (2004). A Software En-gineering Framework for Context-Aware PervasiveComputing. 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 approachfor provisioning, configuring, and managing infras-tructure resources in the cloud. Diploma thesis, Uni-versity of Stuttgart, 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 provision-ing: Bridging the gap between declarative object mod-els and 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 canbe done about 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.


509

Documents

Context-aware Cloud Application Management 2014/CLOSER... · Java. Especially the more and more emerging script-centric conﬁguration management technologies such as Chef (Nelson-Smith,