1054 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 6, NO.

4, OCTOBER-DECEMBER 2018

Middleware-Oriented Deployment Automation

for Cloud Applications
Johannes Wettinger, Vasilios Andrikopoulos, Frank Leymann, and Steve Strauch

Abstract—Fully automated provisioning and deployment of applications is one of the most essential prerequisites to make use of the
benefits of Cloud computing in order to reduce the costs for managing applications. A huge variety of approaches, tools, and providers
are available to automate the involved processes. The DevOps community, for instance, provides tooling and reusable artifacts to
implement deployment automation in an application-oriented manner. Platform-as-a-Service frameworks are available for the same
purpose. In this work we systematically classify and characterize available deployment approaches independently from the underlying
technology used. For motivation and evaluation purposes, we choose Web applications with different technology stacks and analyze
their specific deployment requirements. Afterwards, we provision these applications using each of the identified types of deployment
approaches in the Cloud to perform qualitative and quantitative measurements. Finally, we discuss the evaluation results and derive
recommendations to decide which deployment approach to use based on the deployment requirements of an application. Our results
show that deployment approaches can also be efficiently combined if there is no ‘best fit’ for a particular application.

Index Terms—Middleware-oriented deployment, application-oriented deployment, Cloud computing, DevOps, decision support

Ç
1 INTRODUCTION

P and relatively cheap infrastructure offerings such

UBLIC
as Amazon Web Services1 are the foundation for the
popularity and success of Cloud computing. Following the
provider-driven automation of the offered middleware
solutions is leveraged by application developers. The imple-
mentation of holistically automated deployment processes
Infrastructure as a Service (IaaS) delivery model [1], resources is especially driven by the rapidly emerging DevOps para-
such as virtual machines and virtual disks can be provi- digm [2], [3] and continuous delivery practices [4], [5].
sioned and decommissioned on demand, so the customers The research presented in this article builds on our previ-
only pay for what they are actually using. According to the ous work [6], [7] and focuses on the characterization of these
NIST definition of Cloud computing [1] services provided deployment approaches, with the intention of identifying
through the Cloud are not limited to the infrastructure level the most efficient deployment of different types of applica-
to provision infrastructure resources such as computing tion stacks on PaaS and IaaS solutions. The overall goal of
power and storage. There are higher-level service delivery our work is to build the foundation for a decision support
models available, namely Platform as a Service (PaaS) and system for Cloud application deployment. In addition, this
Software as a Service (SaaS). As the Cloud service market is work addresses some of the open issues identified in [6]
becoming more mature, these service models gain more and [7], in terms of providing an extended evaluation of
traction in the market with further offerings such as the the discussed approaches. Beside refined measurements
Google App Engine2 becoming available. In particular in and presentation of results, we evaluated the reusability of
the case of the PaaS model, providers essentially offer deployment artifacts when following different deployment
Cloud-enabled middleware solutions to their customers. automation strategies. Thus, the original findings of [7] are
Such solutions can either be provided as middleware services refined and the resulting lessons learned are further refined.
(e.g., database as a service) or reusable middleware compo- Moreover, we provide a comprehensive, systematic analysis
nents that can be used as a foundation to deploy the actual and categorization of the state of the art as a foundation for
application components. Different deployment approaches our work. The main contributions of this work can therefore
are available in this environment, depending on how the be summarized as follows:
 We present a systematic classification of the state of
1. Amazon Web Services: http://aws.amazon.com. the art and the limitations of current operations auto-
2. Google App Engine: https://cloud.google.com/appengine. mation approaches.
 Based on this classification, we define and character-
 The authors are with the Institute of Architecture of Application Systems, ize two distinct types of deployment approaches.
University of Stuttgart, Stuttgart, Germany.
E-mail: {wettinger, andrikopoulos, frank.leymann, strauch}@iaas.uni-  We analyze the deployment requirements of three dif-
stuttgart.de. ferent applications covering some of the most popu-
Manuscript received 11 July 2014; revised 22 July 2015; accepted 14 Feb. lar technologies for building Web applications today.
2016. Date of publication 26 Feb. 2016; date of current version 5 Dec. 2018.  Based on these requirements, we implement the auto-
Recommended for acceptance by J. Fortes. mated deployment of all three applications using
For information on obtaining reprints of this article, please send e-mail to:
[email protected], and reference the Digital Object Identifier below. both types of deployment approaches and different
Digital Object Identifier no. 10.1109/TCC.2016.2535325 Cloud infrastructures for evaluation purposes. This
2168-7161 ß 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See ht_tp://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: St. Xavier's Catholic College of Engineering. Downloaded on August 20,2024 at 04:44:10 UTC from IEEE Xplore. Restrictions apply.
 WETTINGER ET AL.: MIDDLEWARE-ORIENTED DEPLOYMENT AUTOMATION FOR CLOUD APPLICATIONS 1055

Web applications. In the context of our current research we

focus on Web applications as a major class of applications,
which is highly relevant for diverse fields such as software as
a service, mobile apps, and the Internet of things. The topolo-
gies of all three applications consist of middleware components,
application components, and external services.
Taxi App. An overview of the Taxi App’s architecture
developed in the scope of the European Project 4CaaSt as a
demonstrator of the PaaS offerings of the project is shown
in Fig. 1 [8]. A service provider offers taxi management soft-
ware as a service to different taxi companies, i.e., tenants.
Taxi company customers, who are users of the tenant, sub-
mit their taxi transportation requests to the company that
they are registered with. The taxi management software
(back-end) is realized as a set of business processes using
Fig. 1. Architecture of the Taxi Application.
BPEL [9]. The taxi management software leverages context
results in eight deployment scenarios for which we integration processes also implemented in BPEL to retrieve
measure both qualitative and quantitative properties and context information about taxi cabs such as location and
we derive a number of findings. taxi driver contact details from the 4CaaSt platform-
 We present a list of lessons learned based on these provided Context as a Service. Moreover, Google Maps
findings that can be used to support decision making Web Services [10] provide distance calculations between the
concerning which deployment approach is more pick-up location and the location of the taxi cab. All BPEL
appropriate for a particular application. processes are deployed in the open source BPEL engine
The remaining of this article is structured as follows: Sec- Orchestra5 version 4.9.0-M3, which itself is deployed in the
tion 2 introduces the applications to be used for evaluation Java Open Application Server (JOnAS)6 version 5.3.0-M4.
purposes and analyzes their specific deployment require- The taxi company-specific front-ends consist of a Customer
ments in order to motivate our work. Based on our investiga- GUI and a Taxi Drivers’ GUI, which are both deployed in
tion of the state of the art in Section 3, two major types of JOnAS version 5.3.0-M4. The multi-tenant, open source
deployment automation approaches are identified in Section Enterprise Service Bus ESBMT [11] as messaging middle-
4. Our evaluation of these deployment approaches is pre- ware (Fig. 1) enables loose coupling and provides a flexible
sented in Section 5 based on the three applications and their integration solution by avoiding hard-coded point-to-point
deployment requirements described in Section 2. The evalua- connections. ESBMT is based on Apache ServiceMix7 version
tion results are discussed in Section 6, including the reporting 4.3.0 and comes with three registries realized as Post-
of our findings. Furthermore, an initial list of lessons learned greSQL8 version 9.1 databases [12].
is derived from these findings. Finally, Section 7 concludes SugarCRM. Fig. 2 provides an overview of the architec-
this article and provides an outlook in terms of future work. ture of SugarCRM,9 an open source Customer Relationship
Management Software (CRM), which is used for interopera-
2 MOTIVATION bility demonstration purposes by the technical committee of
the Topology and Orchestration Specification for Cloud
In this section we introduce the three applications that are Applications (TOSCA) [13]. All relevant data such as con-
realized based on different technologies (Section 2.1). These tact details of the customers are stored in the SugarCRM
applications are used for the evaluation of the different Database within a MySQL Database Server10 version 5.5.32.
deployment approaches we propose in this paper. More- The SugarCRM Web Application is implemented in PHP
over, we identify application-specific deployment require- and is running on an Apache HTTP Server11 version 2.2.22
ments for all three applications (Section 2.2) to be addressed using a PHP runtime version 5.3.10.
in the evaluation. Chat App: The Chat App’s architecture is presented in
Fig. 3. The user information and the chat logs are stored in
2.1 Applications the Chat Log database using a Redis Database Server12 ver-
We chose the applications Taxi Application (Taxi App), Sug- sion 2.6.14. The Chat App is based on Node.js version
arCRM, and Chat Application (Chat App) because they cover a 0.10.13.13 All clients (Web browsers) communicate with the
set of the most important and established technologies used Node.js-based chat server using the WebSocket14 protocol.
for Web application development today. These are in particu-
lar, Java EE and Web services, PHP and the LAMP stack, and
Node.js, respectively. As confirmed by various programming 5. OW2 Orchestra: http://orchestra.ow2.org.
language and technology stack popularity statistics such 6. OW2 JOnAS: http://jonas.ow2.org.
7. Apache ServiceMix: http://servicemix.apache.org.
as GitHut3 and LangPop,4 these applications target the 8. PostgreSQL: http://www.postgresql.org.
current TOP 5 technology stacks, and can therefore be consid- 9. SugarCRM: http://www.sugarcrm.com.
ered as representative for a significantly large set of today’s 10. MySQL Server: http://www.mysql.com.
11. Apache HTTP Server: http://httpd.apache.org.
12. Redis: http://redis.io.
3. GitHut: http://githut.info. 13. Node.js: http://nodejs.org.
4. LangPop: http://langpop.com. 14. WebSocket: https://www.websocket.org.
Authorized licensed use limited to: St. Xavier's Catholic College of Engineering. Downloaded on August 20,2024 at 04:44:10 UTC from IEEE Xplore. Restrictions apply.
 1056 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 6, NO. 4, OCTOBER-DECEMBER 2018

Fig. 2. Architecture of SugarCRM. Fig. 3. Architecture of the chat application.

In the next section we define the general and application- additional WAR files (customer GUI and taxi driv-
specific deployment requirements for each of the three ers’ GUI) to the JOnAS application server.
applications introduced. These requirements have to be TR2 Registration and configuration of tenant endpoints: In
considered when creating corresponding deployment plans. order to register and configure tenant endpoints
A deployment plan (e.g., a script) implements the logic nec- inside ESBMT several SOAP messages need to be
essary to deploy application or middleware components. sent to its management interface both upon initial
deployment of the application and when addi-
tional tenants are deployed. For the Taxi App
2.2 Deployment Requirements these messages are sent by running a number of
It can be easily observed that there are requirements that test cases by SoapUI’s15 command line-based test
apply to the deployment of all three presented applica- runner.
tions. Since the scope of our research is on deployment TR3 Modification of WAR files: The WAR files that are
automation and approaches for its technical implementa- deployed both upon the application’s initial deploy-
tion we are focusing only on technically relevant deploy- ment and when adding further tenants need to be
ment requirements. We therefore do not consider modified at deployment time. This is because they
additional non-functional requirements regarding perfor- need to connect to the tenant endpoints registered in
mance, costs, compliance, etc. As such, the following ESBMT. Therefore, the address of the corresponding
general deployment requirements need to be considered tenant endpoint and the tenant ID have to be stored
in this context: inside a properties file located in the WAR file.
GR1 Middleware deployment: Configurable deployment In contrast to the Taxi App (and the Chat App, later) the
plans are required to deploy all middleware compo- deployment automation of SugarCRM as described in [14]
nents involved, such as the JOnAS application server was realized with distributed deployment in mind, meaning
for the Taxi App, or the MySQL database server for that the application and the database are hosted on two dif-
SugarCRM. ferent virtual machines. When automating the deployment
GR2 Application deployment: Configurable deployment of SugarCRM, the following requirements were identified:
plans are required to deploy all application compo- SR1 Permission settings: The permissions of particular files
nents on top of the middleware, such as the customer and directories of the PHP application need to be set.
user interface for the Taxi App or the chat log data- As an example, the cache directory needs to be writ-
base for the Chat App. able. This is a typical requirement for the deploy-
GR3 Wiring of components: The middleware as well as the ment of PHP applications.
application components are not deployed in an iso- SR2 Silent installation: After extracting and placing all the
lated manner. Application components need to be PHP script files of the application, a so called silent
wired with each other, or with some of the middle- installation needs to be triggered by calling the
ware components to enable communication between install.php script using an HTTP GET request.
components as outlined in Figs. 1, 2, and 3. As a result, the database structure is created and the
Further requirements regarding the design of deploy- application gets configured by creating a default
ment plans such as modularity, configurability, extensibil- user (administrator).
ity, and portability are discussed in [6]. In addition to these SR3 Dynamic wiring at deployment time: The SugarCRM
general requirements, each presented application imposes application needs to be wired with the database
additional deployment requirements. For the Taxi App [11] dynamically at deployment time; the endpoint of the
we identified the following requirements when we imple- database needs to be put to the application’s con-
mented its automated deployment: figuration, so the connection can be established (this
TR1 Deployment of additional tenants: After the initial requirement is a refinement of GR3 ).
deployment has been performed, mechanisms are Compared to the Taxi App and SugarCRM, the Chat
needed to deploy additional tenants. This involves App’s architecture is relatively simple. Thus, automating
sending SOAP messages to the Web service-based
management interface of ESBMT as well as deploying 15. SoapUI: http://www.soapui.org.
Authorized licensed use limited to: St. Xavier's Catholic College of Engineering. Downloaded on August 20,2024 at 04:44:10 UTC from IEEE Xplore. Restrictions apply.
 WETTINGER ET AL.: MIDDLEWARE-ORIENTED DEPLOYMENT AUTOMATION FOR CLOUD APPLICATIONS 1057

Fig. 4. Categorized State of the Art Approaches to Implement Operations Automation.

the deployment based on deployment plans is easier. There as a key part of a certain operations automation approach
were two requirements identified during the implementa- because operating applications as described in Section 2
tion of the deployment plans: needs to cover additional aspects beside deployment.
Typical examples include doing a database backup or scal-
CR1 Node package manager integration: Node.js applications ing certain parts of the application. Thus, we consider the
such as the Chat App typically provide a package. automated deployment of middleware and application
json file that holds some metadata of the application components as a sub-discipline of operations automation.
as well as its dependencies on other Node.js modules. Fig. 4 categorizes state of the art approaches to imple-
These dependencies are resolved at deployment time ment operations automation. The categories are arranged
using the node package manager (npm).16 in a hierarchic structure with leaves grouping the actual
CR2 Pointer to application’s entry point: Node.js applications automation approaches. Approaches in each leaf group
typically consist of several scripts implemented in (category) in the hierarchy are further classified to one of
JavaScript. To start such an application, a particular three types: (1) a provider-dependent approach such as using
script needs to be defined as entry point. This script is a PaaS solution offered by a certain provider (e.g., Her-
then called by the Node.js runtime environment to oku17), (2) a tooling-dependent approach such as an abstrac-
initialize and start the actual application. tion library to interact with multiple providers (e.g., fog18),
Different applications have therefore different require- or a piece of software that does not have any dependencies
ments regarding their deployment. These individual require- on certain providers (e.g., Docker [15]). Some of the pro-
ments have to be taken into account when implementing vider-dependent approaches are implicitly tooling-depen-
plans to automate the deployment process of a particular dent, too. For instance, Amazon provides a set of tools19 to
application. In principle, there exist different approaches to interact and integrate with their services programmatically.
realize deployment automation such as the one described in (3) Moreover, standards-based approaches exist such as the
[6]. Because there is not a single approach that fits all the dif- Topology and Orchestration Specification for Cloud Appli-
ferent requirements, it is necessary to be able to identify the cations [16], which enables model-based management of
most suitable approach for each type of application. Thus, in Cloud applications and infrastructure resources.
the following we categorize existing approaches to automate Platform-centric management approaches enable deploy-
operations especially focusing on automated deployment. ment in the PaaS model. These are usually based on pro-
However, all relevant deployment requirements for a par- vider-dependent platform offerings such as Google App
ticular application must be satisfied when implementing Engine [17] or Amazon Elastic Beanstalk [18]. The goal of
its automated deployment using any of the categorized the PaaS model is to provide a platform that abstracts from
approaches, i.e., the identified requirements are orthogonal the underlying infrastructure resources and provides
to the approaches outlined in the following classification. “middleware as a service”. Thus, the application com-
ponents are directly hosted on the platform. To host the
3 STATE OF THE ART Taxi App, SugarCRM, or Chat App using the PaaS model,
several “middleware services” are required to be exposed
In the following we survey various deployment approaches
from the literature. We consider each deployment approach
17. Heroku: http://www.heroku.com.
18. fog: http://github.com/fog/fog.
16. npm: http://npmjs.org. 19. AWS tools: http://aws.amazon.com/tools.
Authorized licensed use limited to: St. Xavier's Catholic College of Engineering. Downloaded on August 20,2024 at 04:44:10 UTC from IEEE Xplore. Restrictions apply.
 1058 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 6, NO. 4, OCTOBER-DECEMBER 2018

by the platform. These middleware services can for exam- OpenStack [21] available to create an IaaS environment for
ple provide an ESB, a BPEL engine, or a database server deploying VM images. The Open Virtualization Format
depending on the topology of the corresponding applica- (OVF) [22] aims to be a standardized format for such images.
tion. As these middleware services may not be offered These are all hypervisor-based virtualization approaches,
out of the box by PaaS providers, a custom PaaS environ- meaning the granularity is always on the level of a complete
ment can be built based on existing infrastructure resour- VM. Container-based virtualization approaches (e.g., Docker)
ces, e.g., inside the private boundaries of a particular enables to further virtualize a VM. Consequently, different
organization. As an example, the PaaS framework Cloud middleware and application components can be encapsu-
Foundry20 enables a tooling-dependent platform-centric lated in container images.
management approach. All platform-centric approaches For each of the three applications introduced in Section 2,
have the drawback of restricting control over the under- a VM image could be created to host the whole application,
lying infrastructure. For instance, the filesystem cannot or each application component can be hosted on a separate
by accessed in most cases. Moreover, the programming VM, or on a separate container on the same or different
model is often limited to the use of certain frameworks VMs. Another possibility is a compromise between both
and APIs. This is necessary in most cases to implement options by hosting some components on separate VMs and
an efficient layer of abstraction for the services offered by other components of the same application to be grouped
the platform. together to be hosted in the same VM, e.g., depending on
Higher-level model-based management approaches enable the resource requirements of each component. Several
the definition of a holistic application-centric model of a par- approaches are available that are focused on optimized pro-
ticular Cloud service for the deployment, its structure and visioning of virtual machines and deploying virtual
behavior. Such a holistic model can be provider-dependent machine images such as [23], [24], and [25].
(e.g., AWS OpsWorks [19]), tooling-dependent (e.g., Juju21 Focusing on the IaaS model, the alternative is to use
or Blueprints [20]), or standards-based (e.g., TOSCA [16]). standard images that basically provide only a plain operat-
In addition, there are commercial products available that ing system, instead of completely pre-installed and pre-
implement the model-based approach. An example of these configured images. Plan-based configuration management
products is the IBM SmartCloud Orchestrator.22 The goal of approaches proposed by the DevOps community such as
the model-based approach is to enable top-down modeling Chef [26], [27], Puppet [28], [29], CFEngine [30], Smart-
by starting with a higher-level model for a Cloud applica- Frog [31], or Engage [32] can be used to install and configure
tion. To enable the deployment of such a model, additional the actual middleware and application components. Scripts
artifacts such as scripts may have to be attached to the are used to perform the installation and configuration [33].
model to perform the actual deployment of the components Conventional workflow approaches such as BPEL [9] or
that are involved. BPMN [34] may also be utilized to implement plans that per-
Another model-based technique is to create infrastructure- form these tasks. In order to manage topologies that consist
centric models. For instance, AWS CloudFormation23 enables of several machines and different components hosted on
the creation of provider-dependent models by defining a them, overarching plans or model-based approaches such as
set of resources such as virtual machines (VMs). Further- AWS CloudFormation, AWS OpsWorks, or Juju can be used.
more, scripts can be embedded to install and configure mid- An efficient way of combining configuration management
dleware and application components on these machines. with model-based management is described in [14]. In addi-
However, in contrast to the application-centric models dis- tion, there are model-based approaches such as En-
cussed before, these models focus on the orchestration of Stratus [35] or RightScale25 that use Chef scripts in the
resources on the infrastructure level and do not explicitly background to perform the actual deployment. For the three
define relations between middleware and application applications considered in this work this deployment
components. approach implies to have at least several scripts to install
The configuration management approaches can be seen as and configure all the middleware and application compo-
nents that are involved. In addition, there may be an over-
an alternative or a complement to the model-based app-
arching model that orchestrates all scripts involved.
roaches. Either plan-based approaches or image-based virtuali-
The automation approaches shown in Fig. 4 are not
zation techniques can be used to implement operations
meant to be mutually exclusive. For instance, configuration
automation, most probably under some kind of version con-
management is mainly focused on installing and configuring
trol. Plans such as scripts are used to install and configure
middleware and application components on an infra-
middleware and application components. The image-based
structure. However, to provision infrastructure resources
approach with respect to the IaaS service model encapsulates
such as virtual machines, infrastructure management
the different middleware and application components in VM
approaches are typically required. Moreover, there are
images. Today, there are many IaaS providers offering the
extensions for some configuration management tools such
deployment of VM images such as Amazon Web Services
as Chef knife plugins26 to cover infrastructure manage-
(AWS).24 In addition, there are open source products such as
ment aspects, so these two management disciplines can
be integrated seamlessly. To reduce dependencies on pro-
20. Cloud Foundry: http://www.cloudfoundry.org. viders and tools, standards are emerging in all categories.
21. Juju: http://juju.ubuntu.com.
22. IBM SmartCloud Orchestrator: http://ibm.co/CPandO.
23. AWS CloudFormation: http://aws.amazon.com/cloudformation. 25. RightScale and Chef integration: http://goo.gl/sn1OtT.
24. Amazon Web Services: http://aws.amazon.com. 26. Chef knife plugins: https://docs.chef.io/plugin_knife.html.
Authorized licensed use limited to: St. Xavier's Catholic College of Engineering. Downloaded on August 20,2024 at 04:44:10 UTC from IEEE Xplore. Restrictions apply.
 WETTINGER ET AL.: MIDDLEWARE-ORIENTED DEPLOYMENT AUTOMATION FOR CLOUD APPLICATIONS 1059

Some examples are Cloud Infrastructure Management application. In addition, the deployment plans involved
Interface (CIMI) [36] on the level of infrastructure man- are typically hard-wired, i.e., they have explicit dependen-
agement, OVF for VM images (hypervisor-based virtuali- cies that cannot be exchanged dynamically without chang-
zation), and TOSCA for model-based management. ing the plans themselves. To provide an approach enabling
the creation of deployment plans with improved reusabil-
ity, in [6] we proposed the middleware-oriented deployment
4 PLAN-BASED DEPLOYMENT AUTOMATION
approach:
In the previous section we discussed plan-based configuration Middleware-oriented deployment: Generic and reusable mid-
management as an operations automation approach, and as dleware components that are not bound to a specific application
an enabler for several other approaches to implement the auto- enable the deployment of Cloud applications including (i) the mid-
mated deployment of middleware and application compo- dleware functionality required by the application and (ii) the
nents. For instance, plans such as scripts are attached to application components involved.
topology models of applications in order to make them In this case, application deployment is performed by
deployable. Furthermore, plans are used to install and con- parameterizing and executing portable deployment plans
figure software components hosted on virtual machines that are attached only to the middleware components.
and containers. Platform-centric management environments We assume that middleware components are not bound to
based on PaaS frameworks can be set up and operated specific applications, so these middleware components
based on such plans. Thus, in the following we focus on including their deployment plans can be reused to deploy
characterizing, refining, and evaluating plan-based approaches to different applications of the same type. There are no deploy-
implement deployment automation as a key part of operations ment plans attached to any application component when fol-
automation. lowing the pure middleware-oriented deployment approach.
Taking a look at the state of the art, the DevOps commu- Consequently, an overarching orchestration model or system
nity focuses on providing pragmatic solutions for the auto- to wire multiple deployment plans as it is typically required
mation of application deployment. Technically, this is often for non-trivial application stacks can purely focus on the con-
(immediately or implicitly) based on plan-based configura- figuration of reusable plans. This is in contrast to developing
tion management approaches, which drive the following individual application-specific plans and corresponding
discussions and evaluation presented in this article. The orchestration models, which are hard to reuse.
focus is on deploying predefined application stacks across In case the application components are not bound to
several (virtual or physical) machines. Reusability only specific middleware components, this approach enables
occurs when similar application stacks are being deployed middleware abstraction. Consequently, particular middleware
by the same teams of people. Such a deployment can be components can be arbitrarily exchanged, e.g., based on
characterized as application-oriented. The communities affili- functional or non-functional requirements. As an example,
ated with some of the popular DevOps tools such as [6] shows how the JOnAS application server in the Taxi App
Chef [26] or Puppet [28] provide artifacts such as Chef cook- stack can be exchanged by a Tomcat servlet container.
books27 to build deployment plans for certain application
Because the Tomcat servlet container consumes less memory
stacks. Deployment plans based on these artifacts can be
and gets deployed faster, it could be typically used in a
used to automate the deployment of the applications
development environment instead of deploying a complete
described in Section 2.1. Such plans can be implemented as
application server such as JOnAS.
Chef cookbooks by (i) orchestrating existing cookbooks
The Chef community has published cookbooks that can
that are already available and (ii) implementing some
be classified under the middleware-oriented deployment
application-specific deployment logic. Existing cookbooks
approach such as the application_php28 cookbook to
are typically available to deploy popular middleware com-
deploy arbitrary applications or application components
ponents such as an Apache HTTP server or a PHP runtime
implemented in PHP. However, these cookbooks do not
environment. Consequently, this deployment approach can
enable middleware abstraction because they contain hard-
be summarized as follows:
wired dependencies to other middleware components.
Application-oriented deployment: Application-specific but por-
For example, the application_php cookbook mentioned
table deployment plans enable the deployment of a particular
before has a hard-wired dependency to the Apache HTTP
application including all application components and middleware
server as its underlying middleware. Consequently, this
components involved.
middleware component that provides a PHP runtime
The portability of deployment plans enables infrastruc-
environment cannot be exchanged dynamically without
ture abstraction [6], meaning that the plans are not bound to
changing the cookbook. In addition, these cookbooks
a specific infrastructure such as a particular XaaS provider.
cannot be used as deployment plans that can be parame-
As an example, most of the cookbooks provided by the
terized. Usually, they provide resources that can be used
Chef community realize infrastructure abstraction because
in other cookbooks. A developer needs to create an addi-
Chef cookbooks are implemented using a domain-specific
tional deployment plan that implements the configuration
language that is not bound to a specific platform. Deploy-
and wiring of these resources. Consequently, these cook-
ment plans that follow the application-oriented deploy-
books cannot be immediately used as middleware-oriented
ment approach are typically limited in their reuse because
deployment plans as they are.
they were created to automate the deployment of a specific

27. Chef supermarket: https://supermarket.chef.io. 28. https://supermarket.chef.io/cookbooks/application_php.

Authorized licensed use limited to: St. Xavier's Catholic College of Engineering. Downloaded on August 20,2024 at 04:44:10 UTC from IEEE Xplore. Restrictions apply.
 1060 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 6, NO. 4, OCTOBER-DECEMBER 2018

TABLE 1
Types and Input Parameters of Deployment Plans

Plan Type Input Parameters

Application-oriented deployment of Taxi App:
ESBMT Middleware DB credentials
PostgreSQL Middleware DB credentials
JOnAS Middleware JOnAS configuration
Orchestra Middleware none
App_Helper_Services App Specific none
App_ESB_Components App Specific none
PostgreSQL_DBs App Specific DB credentials
App_BPEL_Processes App Specific none
App_Tenant App Specific URLs of WAR files (taxi driver GUI, customer GUI), URL of SoapUI test
suite
Middleware-oriented deployment of Taxi App:
ESBMT Middleware & App Generic DB credentials, URLs of SoapUI test suites
PostgreSQL Middleware & App Generic DB credentials, DB specifications
JOnAS Middleware & App Generic JOnAS configuration, URLs of preprocessed WAR files (taxi driver GUI,
customer GUI)
Orchestra Middleware & App Generic URLs of BPEL processes
Application-oriented deployment of SugarCRM:
Apache_HTTP_Server Middleware Apache configuration
PHP_Runtime_Env Middleware none
MySQL Middleware none
SugarCRM_DB App Specific DB credentials
SugarCRM_App App Specific none
Connect_App_to_DB App Specific DB credentials
Middleware-oriented deployment of SugarCRM:
Apache_HTTP_Server Middleware & App Generic Apache configuration, URL of ZIP file (SugarCRM PHP scripts),
permission information
PHP_Runtime_Env Middleware & App Generic none
MySQL Middleware & App Generic DB credentials
Connect_App_to_DB App Specific DB credentials, SugarCRM admin password
Application-oriented deployment of Chat App:
Node.js Middleware none
Redis Middleware none
Chat_App App Specific none
Middleware-oriented deployment of Chat App:
Node.js Middleware & App Generic URL of ZIP file (Chat App scripts)
Redis Middleware none

In the following we evaluate these types of approaches implemented as Chef cookbooks. However, we do not rely
using the applications presented in Section 2.1 as the means on any unique feature of Chef, so the deployment plans can
to identify which approach fits better which application. be implemented using different deployment automation
tools such as Puppet, Juju,29 OpenTOSCA,30 and other plan-
5 EVALUATION based management approaches [37]. Each plan is character-
ized by its type: middleware means that the plan deploys one
For evaluation purposes we implemented deployment
or more middleware components. Plans of type middleware &
plans to automate the deployment of all three applica-
app generic are typically used for the middleware-oriented
tions described in Section 2.1 using both the application-
oriented and the middleware-oriented approach. This deployment approach to deploy middleware components as
results in six different deployment scenarios (three app- well as application components on top of them as discussed
lications multiplied by two approaches). In addition, in [6]. App specific plans are mostly used for the application-
we deploy the SugarCRM application in two manners oriented deployment approach because they implement spe-
(centralized in one VM, and distributed across different cific logic to automate the deployment of particular applica-
VMs), again using both the application-oriented and the tion components. Furthermore, the input parameters (Chef
middleware-oriented deployment approach to further attributes) for each plan are identified. Figs. 5 and 6 show the
broaden the scope of our evaluation. This adds two addi- dependencies between plans when following the applica-
tional deployment scenarios, so our evaluation covers tion-oriented or the middleware-oriented deployment.
eight deployment scenarios in total.
Table 1 provides an overview of all deployment plans 29. Juju: http://juju.ubuntu.com.
involved in the scenarios. Technically, all plans are 30. OpenTOSCA: http://www.iaas.uni-stuttgart.de/OpenTOSCA.
Authorized licensed use limited to: St. Xavier's Catholic College of Engineering. Downloaded on August 20,2024 at 04:44:10 UTC from IEEE Xplore. Restrictions apply.
 WETTINGER ET AL.: MIDDLEWARE-ORIENTED DEPLOYMENT AUTOMATION FOR CLOUD APPLICATIONS 1061

Fig. 6. Plan dependencies for middleware-oriented deployment.

High Dynamic processing of arbitrary application

components of a particular type.
 Assumption Freedom: This refers to the number of
Fig. 5. Plan dependencies for application-oriented deployment. assumptions made regarding the input of a particu-
lar deployment plan. Obviously this can only be
All deployments have been performed using two differ- measured in case the plan has any input parameters
ent Cloud infrastructures: FlexiScale31 and Amazon Web at all. Measurable degrees:
Services EC2,32 in order to ensure independence from a spe- Low Application-specific assumptions, e.g., a ten-
cific provider. Table 2 shows the evaluation settings in ant ID needs to be written into a WAR file
detail: the Taxi App has been deployed on Ubuntu Linux (application component) either by the dep-
10.04 Server (64-bit) on a virtual machine providing two loyment plan itself or by some kind of
CPU cores and 4 GB (FlexiScale) or 7.5 GB (AWS EC2) of preprocessor.
RAM. Both SugarCRM and the Chat App have been Med Common assumptions for the corresponding
deployed on Ubuntu Linux 12.04 Server (64-bit) based on 1 type of application component, e.g., a Node.js
CPU core and 1 GB (FlexiScale) or 1.7 GB (AWS EC2) of application typically owns a package.json
RAM. For the distributed SugarCRM deployment, two vir- file that specifies its dependencies.
tual machines were used: one for the database and another High No specific assumptions.
one for the application itself. Each machine has one CPU  Reusability: The following degrees specify the reus-
core and 1 GB (FlexiScale) or 1.7 GB (AWS EC2) of RAM. ability of a particular deployment plan:
The deployment of the database was running in parallel to Low No reusability, i.e., the plan was specifically
the deployment of the actual application. Then, these two created for a particular application.
machines were dynamically wired at deployment time by Med The plan can be used to deploy reusable but fixed
exchanging the database endpoint information using an components such as middleware components
AWS S3 bucket33. In all cases we are using hypervisor-based that are required in different application stacks.
VMs with a plain operating system running the plans High The plan can be used to deploy arbitrary app-
(Chef cookbooks) on top of it, i.e. no pre-configured VM lication components of a particular type.
images are used. Consequently, we are clearly following Table 3 shows the measured degrees for the properties
the plan-based configuration management approach as flexibility, assumption freedom, and reusability for each
discussed in Section 3. deployment plan.
For each deployment scenario, five measurements are
performed in total. These include three qualitative and three 5.2 Quantitative Measurements
quantitative measurements. In addition to the qualitative measurements, we also mea-
sure the following three quantitative properties for each
5.1 Qualitative Measurements deployment scenario:
First, we measure the following three qualitative properties  Total complexity: This property expresses the number
for each deployment plan. For all three properties we use of “atomic actions”, i.e., Chef resources34 executed
an ordinal Low/Medium/High scale, from worst to best: during deployment.
 Total number of plan dependencies: This is the total
 Flexibility: This property expresses the degree of cus-
number of dependencies between plans for a partic-
tomizability by configuring a particular deployment
ular deployment scenario.
plan using input parameters at runtime. Measurable
 Total execution time: This is the total time required for
degrees:
the execution of all deployment plans involved in a
Low No input parameters, i.e., no dynamics at
single scenario, measured in seconds.
runtime.
Table 4 shows the measured total complexity of each
Med Configuration options for predefined compo-
deployment scenario, i.e., the number of Chef resources exe-
nents, e.g., database credentials.
cuted at deployment time for a particular deployment
scenario. Moreover, Figs. 5 and 6 compare the total number
31. FlexiScale: http://www.flexiscale.com.
32. AWS EC2: http://aws.amazon.com/ec2.
33. AWS S3: http://aws.amazon.com/s3. 34. Chef resources: https://docs.chef.io/resource.html.
Authorized licensed use limited to: St. Xavier's Catholic College of Engineering. Downloaded on August 20,2024 at 04:44:10 UTC from IEEE Xplore. Restrictions apply.
 1062 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 6, NO. 4, OCTOBER-DECEMBER 2018

TABLE 2 TABLE 3
Evaluation Settings Qualitative Measurements of Deployment Plans

Application Machine Type #VMs Plan Flexi- Assum. Re-

FlexiScale: bility Freedom usability
Taxi App 2 CPU cores, 4 GB memory 1 Application-oriented deployment of Taxi App:
SugarCRM 1 CPU core, 1 GB memory 1 ESBMT Med High Med
SugarCRM (distrib.) 1 CPU core, 1 GB memory 2 PostgreSQL Med High Med
Chat App 1 CPU core, 1 GB memory 1 JOnAS Med High Med
Orchestra Low – Med
Amazon Web Services EC2: App_Helper_Services Low – Low
Taxi App 2 CPU cores, 7.5 GB memory 1 App_ESB_Components Low – Low
(m1.large) PostgreSQL_DBs Med High Low
SugarCRM 1 CPU core, 1.7 GB memory 1 App_BPEL_Processes Low – Low
(m1.small) App_Tenant High Low Low
SugarCRM (distrib.) 1 CPU core, 1.7 GB memory 2
(m1.small) Middleware-oriented deployment of Taxi App:
Chat App 1 CPU core, 1.7 GB memory 1 ESBMT High High High
(m1.small) PostgreSQL High High High
JOnAS High Low High
Orchestra High High High
of plan dependencies for each deployed application. Table 5 Application-oriented deployment of SugarCRM:
outlines the average execution time in total for each deploy- Apache_HTTP_Server Med High Med
ment scenario. The average time is based on five deploy- PHP_Runtime_Env Low – Med
ment runs per scenario. MySQL Med – Med
SugarCRM_DB Med High Low
5.3 Reusability of Plans in Practice SugarCRM_App Low – Low
Connect_App_to_DB Med High Low
In order to evaluate the reusability of deployment plans in
practice, we reused the plans created for SugarCRM to deploy Middleware-oriented deployment of SugarCRM:
another PHP-based application, namely WordPress.35 The Apache_HTTP_Server High Low High
PHP_Runtime_Env Low – Med
deployment requirements of WordPress are similar to those
MySQL High High High
of SugarCRM. In case of middleware-oriented deployment Connect_App_to_DB Med High Low
we only had to adapt the Connect_App_to_DB plan
Application-oriented deployment of Chat App:
because the configuration file format for storing the database
Node.js Med – Med
endpoint information is different. However, in case of Redis Med – Med
application-oriented deployment two new plans had to be Chat_App Low – Low
created based on the SugarCRM_DB and SugurCRM_App
Middleware-oriented deployment of Chat App:
plans in addition. These are WordPress_DB and WordPres- Node.js High Med High
s_App to deploy the WordPress application itself as well as Redis Med – Med
the database. In summary, three plans were reused, one plan
was modified, and no additional plan was implemented for
the middleware-oriented deployment; for the application-ori- deployment approach generally improves the reusability of
ented deployment, three plans were reused, one plan was deployment plans. Furthermore, our measurements verify
modified, and two plans were additionally implemented. the observations reported in [6] that the number of
deployment plans decreases when using the middleware-
6 DISCUSSION oriented deployment approach in general. This is due to the
fact that application-specific actions are covered by parame-
Section 5 described the process and results of our evaluation terizing generic deployment plans attached to middleware
based on eight deployment scenarios. This section discusses components.
the evaluation results and presents findings as well as les- However, the pure middleware-oriented deployment
sons learned. In our previous work [6] we evaluated and approach cannot be implemented for all deployment sce-
discussed the impact of using the middleware-oriented narios. Middleware-oriented deployment is typically
deployment approach in order to reduce the number implemented based on plans of type middleware and middle-
of deployment plans for the Taxi App. The evaluation ware & app generic. Because app specific plans are specifically
presented in this paper broadens the horizon by looking created for particular application components they should
beyond the number of plans involved for the deployment of be avoided when following the middleware-oriented
a single application. Therefore, in the following we analyze approach. In case of implementing a middleware-oriented
the measurements reported in the previous section. deployment of SugarCRM, for example, Table 3 shows that
there is a plan to wire the application with the database
6.1 Findings (Connect_App_to_DB). This plan is of type app specific
One of the first findings that can be derived from the evalua- because it cannot be implemented in a generic manner.
tion results shown in Table 3 is that the middleware-oriented As discussed in Section 2.2, the requirements SR2 and SR3
require very application-specific actions to be performed.
35. WordPress: http://www.wordpress.org. These are implemented using the wiring plan.
Authorized licensed use limited to: St. Xavier's Catholic College of Engineering. Downloaded on August 20,2024 at 04:44:10 UTC from IEEE Xplore. Restrictions apply.
 WETTINGER ET AL.: MIDDLEWARE-ORIENTED DEPLOYMENT AUTOMATION FOR CLOUD APPLICATIONS 1063

TABLE 4 TABLE 5
Total Complexity of Each Scenarios Average Total Execution Time  of Deployment Plans and Stan-
dard Deviation s
Application App.-oriented Middleware-oriented
Taxi App 139 139 Application App.-oriented Middleware-oriented
SugarCRM 57 57 FlexiScale:
SugarCRM (distrib.) 57 57 Taxi App  = 899 sec.  = 937 sec.
Chat App 16 16 s = 25 sec. s = 45 sec.
SugarCRM  = 264 sec.  = 262 sec.
s = 9 sec. s = 13 sec.
In case generic deployment plans for deploying applica- SugarCRM (distrib.)  = 184 sec.  = 180 sec.
tion components are attached to middleware components, s = 4 sec. s = 10 sec.
typically assumptions are made beforehand regarding the Chat App  = 219 sec.  = 228 sec.
application components deployed using these plans. For s = 6 sec. s = 11 sec.
instance, the Node.js plan used in the middleware- Amazon Web Services EC2:
oriented deployment expects (i) a package.json file as Taxi App  = 1316 sec.  = 1294 sec.
described in the requirement CR1 and (ii) a pointer to the s = 53 sec. s = 37 sec.
SugarCRM  = 372 sec.  = 358 sec.
script that is the entry point for a particular application
s = 47 sec. s = 36 sec.
(CR2 ). Another example is the JOnAS plan to deploy addi- SugarCRM (distrib.)  = 233 sec.  = 235 sec.
tional tenants (WAR files) for the Taxi App (TR1 , TR3 ). s = 9 sec. s = 16 sec.
The flexibility of deployment plans following the Chat App  = 314 sec.  = 325 sec.
application-oriented deployment approach is, as expected, s = 7 sec. s = 18 sec.
worse compared to middleware-oriented deployment
because their implementation is tightly coupled to specific
application components. They typically expect a few rudi- L1 – Middleware-oriented deployment plans are typically pre-
mentary input parameters only such as configuration ferred for scenarios where conventions for application components
options for the middleware. are already established, so there are no or minimum assump-
When looking at Table 4 it becomes clear that the com- tions regarding the application components. Examples for
plexity of deploying a particular application is equal in both such conventions are the package.json file (requirement
cases, and therefore it does not depend on the deployment CR1 in Section 2.2), setting permissions for PHP applica-
approach chosen. This is because there is no difference on tions (SR1 ), or sending SOAP messages using SoapUI test
the level of “atomic actions”, i.e., on the level of Chef resour- suites (TR2 ). From this perspective, middleware-oriented
ces that are executed at deployment time such as creating a deployment is preferred for the Chat App because the appli-
particular directory, storing a configuration file, or installing cation-specific deployment requirements CR1 and CR2 can
a software package. However, Figs. 5 and 6 denote a be transferred to other Node.js applications.
decreased number of plans and plan dependencies for all L2 – There are application-specific requirements that cannot be
deployed applications in case the middleware-oriented generally transferred to other applications of the same type, so
deployment approach is used. the implementation of middleware-oriented deployment
Table 5 shows minimal differences between application- for the Taxi App and SugarCRM is not as straightforward
oriented and middleware-oriented deployment for the aver- as it is for the Chat App. For SugarCRM the Connec-
age deployment time of each scenario. These measurements t_App_to_DB plan prevents the implementation of pure
match the complexity measurements shown in Table 4: middleware-oriented deployment because application-
because the Chef resources executed at deployment time specific deployment requirements (SR2 , SR3 ) need to be ful-
are the same, it is only logical that there are no significant filled. These cannot be transferred to other PHP applications
differences in terms of the plans’ total execution time. The (e.g., WordPress) in general because the configuration of
minor differences are due to the fact that files (middleware each PHP application is different. For the Taxi App, middle-
and application components) are downloaded from the ware-oriented deployment can be realized. However, to ful-
Web during deployment. Because the quality of the under- fill requirement TR3 , WAR files that are deployed using the
lying HTTP connections for these downloads could differ, JOnAS plan need to be preprocessed before deployment:
there are small deviations. the tenant ID and the tenant endpoint are stored inside the
Our further evaluation of reusability of plans in practice WAR files. Furthermore, TR1 cannot be fulfilled by a single
based on SugarCRM and WordPress (Section 5.3) confirms deployment plan because this is application-specific knowl-
our previous conclusion: middleware-oriented deployment edge. To deploy additional tenants both the JOnAS and the
clearly improves reusability of plans. Moreover, the number ESBMT plans have to be used in combination with certain
of plans that need to be adapted for specific applications can parameters.
be significantly reduced. L3 – In case of distributed deployments, such as we did for
SugarCRM, the wiring logic can be implemented in a middle-
6.2 Lessons Learned ware-oriented manner only if it does not need any application-spe-
Based on the findings presented in the previous section, we cific knowledge of how and where to store the endpoint
now summarize several of the lessons learned to support information. Typically, wiring plans are application-specific
the decision which deployment approach fits which type of such as the Connect_App_to_DB plan in case of deploy-
application: ing SugarCRM. This is because most of the times endpoint
Authorized licensed use limited to: St. Xavier's Catholic College of Engineering. Downloaded on August 20,2024 at 04:44:10 UTC from IEEE Xplore. Restrictions apply.
 1064 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 6, NO. 4, OCTOBER-DECEMBER 2018

information needs to be stored in application-specific con-  Ruby-based applications commonly make use of
figuration files. Bundler41 to process Gemfiles. A Gemfile is used to
L4 – Even if the middleware-oriented deployment approach define both the dependencies and the Ruby version
cannot be implemented completely, a hybrid approach can be real- to be used for a certain application component.
ized. In this case as many deployment plans as possible are  Applications based on Python usually utilize pip42
implemented in a middleware-oriented manner to improve for dependency management. Therefore, a
flexibility and reusability. However, application-specific requirements.txt file must be created to point to
deployment actions are performed using plans that follow other Python packages.
the application-oriented deployment approach. Examples Moreover, PaaS providers implement mechanisms to
for such actions are deploying additional tenants for the expose endpoint information such as the IP address of the
Taxi App (TR1 ) or wiring the SugarCRM application with database instance using context or environment variables.
the database (SR3 ). We followed this approach implicitly These variables can be read, for instance, in a script-based
when we implemented middleware-oriented deployment configuration file (PHP, Python, Ruby, etc.) to connect
for SugarCRM because it is impossible to implement the application components to the database.
logic of the application-specific Connect_App_to_DB plan
in a generic manner. 7 CONCLUSION AND FUTURE WORK
L5 – The usage of middleware-oriented deployment plans The automated provisioning and deployment of applications
instead of application-oriented ones does not affect the total com- on IaaS and PaaS solutions is one of the major enablers in the
plexity of a deployment scenario or the total execution time. reduction of the operational costs by migrating to the Cloud.
Consequently, performance aspects do not have to be con- Tooling and approaches mostly from the DevOps commu-
sidered. Nonetheless, the total number of plans and plan nity have provided the means for such an automation
dependencies can be reduced by following the middleware- through deployment plans. However, these approaches focus
oriented approach. on the deployment of individual, specific application stacks
L6 – However, the development of plans to realize middleware- at a time, sacrificing reusability for efficiency and ease in the
oriented deployment might be more complex for the plan develop- development of such deployment plans. For this reason, in
ers. As shown in Table 3 these plans can be parameterized previous work [6], and approaching the problem from a PaaS
using sets of input parameters. These parameters imply offering perspective, we proposed a middleware-oriented
more dynamics in the plans’ implementation increasing the deployment approach that promotes reusability of deploy-
complexity of the development. The gain of such an invest- ment plans across different applications.
ment is a higher degree of flexibility and reusability as In this work, we expand on previous work to identify
shown in Table 3. and characterize two different types of deployment
approaches (application- and middleware-oriented) based
on a systematic classification of existing operations automa-
6.3 Conventions for Application Components tion approaches presented in the literature and available in
As mentioned in lesson L1 , middleware-oriented deploy- the market. We developed deployment plans for three
ment is typically preferred if common conventions for applications (Taxi App, SugarCRM, and Chat App) with
application components are established. Beside the conven- significantly different deployment requirements using the
tions for Node.js applications (CR1 ) as well as PHP applica- identified approaches, and we evaluated the results across
tions (SR1 ) discussed before, there are further conventions both qualitative and quantitative dimensions. Our findings
that are also implemented by PaaS providers such as show better reusability, portability, and flexibility of
Heroku or Google App Engine: middleware-oriented plans when compared to application-
oriented ones, without a loss in performance (i.e., deploy-
 For Java applications it is common to express all
ment time). The results of our evaluation are independent
dependencies of a particular application component
of a particular Cloud provider. The trade-off however for
using a pom.xml file. These dependencies are
this improvement is in the difficulty of creating such plans.
resolved using Maven36 at deployment time. Fur-
In order to demonstrate the reusability potential of such
thermore, a system.properties37 file can be used
plans in practice we reused the plans created for SugarCRM
to define the Java version required by a particular
to deploy WordPress in an application- and middleware-
application component.
oriented manner. WordPress has a similar application stack
 In case the Java application is built using the Play and comparable deployment requirements. Finally, based
framework,38 dependencies are typically defined on what we derived from this evaluation we provide recom-
using a dependencies.yml file instead of a pom. mendations as lessons learned with respect to deciding
xml file. which approach to use when deploying an application.
 For Scala39 applications a build.properties file is In terms of future work, we plan to extend our evaluation
typically used to specify dependencies. This file gets to cover even more application stacks based on different tech-
processed using sbt40 at deployment time. nologies such as Ruby on Rails or Django based on Python.
Moreover, we aim to broaden the scope of the evaluation by
36. Apache Maven: http://maven.apache.org. considering additional aspects such as the number of code
37. Java system properties: http://goo.gl/ewo78l.
38. Play framework: http://www.playframework.com.
39. Scala: http://www.scala-lang.org. 41. Bundler: http://bundler.io.
40. sbt: http://www.scala-sbt.org. 42. pip: http://www.pip-installer.org.
Authorized licensed use limited to: St. Xavier's Catholic College of Engineering. Downloaded on August 20,2024 at 04:44:10 UTC from IEEE Xplore. Restrictions apply.
 WETTINGER ET AL.: MIDDLEWARE-ORIENTED DEPLOYMENT AUTOMATION FOR CLOUD APPLICATIONS 1065

changes applied to deployment plans over time and training [11] S. Strauch, V. Andrikopoulos, S. G omez Saez, and F. Leymann,
“ESBMT: A multi-tenant aware enterprise service bus,” Int.
costs for developers and operations personnel. Based on this J. Next-Gener. Comput., vol. 4, no. 3, pp. 230–249, 2013.
additional evaluation, further findings and lessons learned [12] S. Strauch, V. Andrikopoulos, S. Gmez Sez, and F. Leymann,
can be derived, in addition to verifying or falsifying the exist- “Implementation and evaluation of a multi-tenant open-source
ing ones. Furthermore, as discussed in the introduction, the ESB,” in Proc. 2nd Eur. Conf. Service Oriented Cloud Comput., 2013,
vol. 8135, pp. 79–93.
overall goal of this work is to provide a decision support sys- [13] OASIS. (2013). Topology and Orchestration Specification for
tem for deployment of applications in the Cloud. Toward Cloud Applications (TOSCA) Version 1.0, Committee Specifica-
this goal, a decision support matrix based on the lessons tion 01 [Online]. Available: http://docs.oasis-open.org/tosca/
TOSCA/v1.0/cs01/TOSCA-v1.0-cs01.html.
learned from this work is currently under development. The [14] J. Wettinger, M. Behrendt, T. Binz, U. Breitenb€ ucher, G. Breiter,
immediate goal of this matrix is to provide the systematic F. Leymann, S. Moser, I. Schwertle, and T. Spatzier, “Integrating
means for decisions related to the creation of deployment configuration management with model-driven cloud manage-
plans, as well as how to use and combine them to automate ment based on TOSCA,” in Proc. 3rd Int. Conf. Cloud Comput
Service Sci., 2013, pp. 437–446.
the deployment of a particular application stack. Based on [15] J. Turnbull, Docker Book. New York, NY, USA: James Turnbull, 2014.
such a matrix, a decision support system prototype can then [16] T. Binz, G. Breiter, F. Leymann, and T. Spatzier, “Portable cloud
be implemented. In this context, existing deployment plans services using TOSCA,” IEEE Internet Comput., vol. 16, no. 3,
such as cookbooks provided by the Chef community can be pp. 80–85, May/Jun. 2012.
[17] D. Sanderson, Programming Google App Engine. Sebastopol, CA,
linked and proposed to the person using the decision support USA: O’Reilly Media, 2009.
system. The decision support system will not only cover [18] J. Vliet, F. Paganelli, S. Wel, and D. Dowd, Elastic Beanstalk. Sebas-
plan-based configuration management approaches, but also topol, CA, USA: O’Reilly Media, 2011.
[19] T. Rosner, Learning AWS OpsWorks. Birmingham, U.K.: Packt Pub-
further operations automation approaches as shown in our lishing Ltd., 2013.
classification. Moreover, we plan to focus on providing [20] M. Papazoglou and W. van den Heuvel, “Blueprinting the cloud,”
decision support on how multiple operations automation IEEE Internet Comput., vol. 15, no. 6, pp. 74–79, Nov./Dec. 2011.
approaches can be combined. For instance, the combination [21] K. Pepple, Deploying OpenStack. Sebastopol, CA, USA: O’Reilly
Media, 2011.
of container virtualization and plan-based configuration [22] DMTF. (2013). Open virtualization format specification (OVF)
management has also to be investigated. Version 2.0.0. [Online]. Available: http://www.dmtf.org/
standards/ovf.
[23] P. Pawluk, B. Simmons, M. Smit, M. Litoiu, and S. Mankovski,
ACKNOWLEDGMENTS “Introducing STRATOS: A cloud broker service,” in Proc. IEEE
5th Int. Conf. Cloud Comput., Jun. 2012, pp. 891–898.
The research leading to these results has partially received [24] S. Zaman and D. Grosu, “An online mechanism for dynamic VM
funding from the EU’s Seventh Framework Programme provisioning and allocation in clouds,” in Proc. IEEE 5th Int. Conf.
(FP7/2007-2013) projects 4CaaSt (grant agreement no. Cloud Comput., Jun. 2012, pp. 253–260.
[25] M. Bjorkqvist, L. Chen, and W. Binder, “Opportunistic service
258862), ALLOW Ensembles (grant agreement no. 600792), provisioning in the cloud,” in Proc. IEEE 5th Int. Conf. Cloud Com-
and from the BMBF project ECHO (01XZ13023G). All links put., Jun. 2012 pp. 237–244.
were last followed on 2016/03/03 12:02:37. [26] S. Nelson-Smith, Test-Driven Infrastructure with Chef. Sebastopol,
CA, USA: O’Reilly Media, Inc., 2013.
[27] M. Taylor and S. Vargo, Learning Chef: A Guide to Configuration
Management and Automation. Sebastopol, CA, USA: O’Reilly
REFERENCES Media, 2014.
[1] P. Mell and T. Grance, “The NIST definition of cloud computing,” [28] J. Loope, Managing Infrastructure with Puppet. Sebastopol, CA,
Nat. Inst. Standards Technol., Gaithersburg, MD, USA, Tech. Rep. USA: O’Reilly Media, Inc., 2011.
SP 800-145, 2009. [29] T. Uphill, Mastering Puppet. Birmingham, U.K.: Packt
[2] J. Humble and J. Molesky, “Why enterprises must adopt devops Publishing, 2014.
to enable continuous delivery,” Cutter IT J., vol. 24, pp. 6–12, 2011. [30] D. Zamboni, Learning CFEngine 3: Automated System Administration
[3] M. H€ uttermann, DevOps for Developers. New York, NY, USA: for Sites of Any Size. Sebastopol, CA, USA: O’Reilly Media, Inc., 2012.
Apress , 2012. [31] P. Goldsack, J. Guijarro, S. Loughran, A. Coles, A. Farrell, A. Lain,
[4] J. Humble and D. Farley, Continuous Delivery: Reliable Software P. Murray, and P. Toft, “The SmartFrog configuration manage-
Releases Through Build, Test, and Deployment Automation. Reading, ment framework,” ACM SIGOPS Operating Syst. Rev., vol. 43,
MA, USA: Addison–Wesley, 2010. pp. 16–25, 2009.
[5] L. Chen, “Continuous delivery: Huge benefits, but challenges [32] J. Fischer, R. Majumdar, and S. Esmaeilsabzali, “Engage:
too,” IEEE Softw., vol. 32, no. 2, pp. 50–54, Mar./Apr. 2015. A deployment management system,” ACM SIGPLAN Notices,
[6] J. Wettinger, V. Andrikopoulos, S. Strauch, and F. Leymann, vol. 47, no. 6, pp. 263–274, 2012.
“Enabling dynamic deployment of cloud applications using a [33] S. G€unther, M. Haupt, and M. Splieth, “Utilizing internal domain-
modular and extensible PaaS environment,” in Proc. IEEE 6thInt. specific languages for deployment and maintenance of IT infra-
Conf. Cloud Comput., Jun./Jul. 2013, pp. 478–485. structures,” Very Large Business Applications Lab Magdeburg,
[7] J. Wettinger, V. Andrikopoulos, S. Strauch, and F. Leymann, Fakult€at f€ ur Informatik, Otto-von-Guericke-Universit€at Magde-
“Characterizing and evaluating different deployment approaches burg, Tech. Rep. FIN-004-2010, 2010.
for cloud applications,” in Proc. IEEE Int. Conf. Cloud Eng., [34] OMG, “Business Process Model and Notation (BPMN) Version
Mar. 2014, pp. 205–214. 2.0,” 2011.
[8] S. Garcıa-G omez, M. Jimenez-Ga~ nan, Y. Taher, C. Momm, [35] enStratus Networks, Inc., “Cloud DevOps: Achieving agility
F. Junker, J. Bır
o, A. Menychtas, V. Andrikopoulos, and S. Strauch, throughout the application lifecycle,” Eden Prairie, MN, USA,
“Challenges for the comprehensive management of cloud services 2012.
in a PaaS framework,” Scalable Comput.: Practice Exp., vol. 13, [36] D. Davis and G. Pilz, “Cloud infrastructure management inter-
no. 3, pp. 201–213, 2012. face (CIMI) model and RESTful HTTP-based protocol,” Distrib-
[9] OASIS, “Web Services Business Process Execution Language uted Management Work Force, Portland, OR, USA, Tech. Rep.
(BPEL) Version 2.0,” 2007. DSP0263, Mar. 2015.
[10] (2016). Google, Inc., Google Maps API Web Services [Online]. [37] U. Breitenb€ ucher, T. Binz, O. Kopp, and F. Leymann, “Pattern-
Available: http://developers.google.com/maps/documentation/ based runtime management of composite cloud applications,” in
webservices. Proc. 3rd Int. Conf. Cloud Comput. Service Sci., 2013, pp. 475–482.

Authorized licensed use limited to: St. Xavier's Catholic College of Engineering. Downloaded on August 20,2024 at 04:44:10 UTC from IEEE Xplore. Restrictions apply.
 1066 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 6, NO. 4, OCTOBER-DECEMBER 2018

Johannes Wettinger is currently working toward Frank Leymann is a full professor of computer
the PhD degree, and a research associate at the science and the director of the Institute of Archi-
Institute of Architecture of Application Systems, tecture of Application Systems, the University of
University of Stuttgart, Stuttgart, Germany. His Stuttgart, Stuttgart, Germany. He has published
research interests include developing and operat- many papers in journals and proceedings, co-
ing continuously delivered software applications, authored four text books, and holds close to
addressing DevOps collaboration and deploy- 50 patents especially in the area of workflow
ment automation. Beside his participation in the management and transaction processing. His
EU-funded project 4CaaSt and his teaching activ- research interests include service oriented com-
ities, he is involved in further projects related to puting and middleware, workflow- and business
cloud computing. process management, cloud computing, transac-
tion processing, integration technology, and architecture patterns. He is
the coauthor of many Web Service specifications, including WSFL, WS-
Vasilios Andrikopoulos received the PhD Addressing, WS-Metadata Exchange, WS-Business Agreement, the
degree from Tilburg University, Tilburg, the WS-Resource Framework set of specifications, WS-HumanTask and
Netherlands, where he was also a member of the BPEL4People; together with Satish Thatte, he was the driving force
European Research Institute in Service Science. behind BPEL4WS. Also, he is the coauthor of BPMN 2.0 and TOSCA.
He is a senior researcher at the Institute of Archi- His background includes having been IBM Distinguished Engineer and
tecture of Application Systems (IAAS) at the Uni- elected member of the IBM Academy of Technology.
versity of Stuttgart, Stuttgart, Germany. His
research interests include the areas of services
science, cloud computing and infrastructures, Steve Strauch is currently working toward the
and software engineering with an emphasis on PhD degree, and is a research associate at the
evolution and adaptation. He has experience in Institute of Architecture of Application Systems,
research and teaching Database Systems and Management, Software University of Stuttgart, Stuttgart, Germany. His
Modeling and Programming, Business Process Management and Inte- research interests include data migration, data
gration, and Service Engineering. He has participated in a number of EU hosting, as well as data security and privacy in
projects, including the NoE S-Cube and 4CaaSt. the area of cloud computing, with an emphasis
on their application architectural aspects. He has
contributed to the European projects COMPAS,
4CaaSt, ALLOW Ensembles, and the German
government funded BMBF project ECHO.

" For more information on this or any other computing topic,

please visit our Digital Library at www.computer.org/publications/dlib.

Authorized licensed use limited to: St. Xavier's Catholic College of Engineering. Downloaded on August 20,2024 at 04:44:10 UTC from IEEE Xplore. Restrictions apply.