Article Preview
Top1. Introduction
Automated provisioning, deployment, and management of Cloud applications are key enablers to reduce operations costs (Leymann, 2009). However, it is hard to implement automated processes for managing applications in production after the actual development is finished. The main reason is that key aspects for operating an application in production were not considered during development. The idea of DevOps (development & operations) aims to eliminate the barrier between developers and operations personnel (Humble and Molesky, 2011; Hüttermann, 2012). Consequently, a highly automated management environment has to be established during development already to continuously deploy and manage new iterations of an application to different environments (e.g., development, test, and production).
When automating such deployment and management processes there are typically a number of building blocks involved: (i) different Cloud providers expose proprietary APIs to provision and manage resources such as storage and virtual machines, whereas (ii) several tools such as Chef (Nelson-Smith, 2013) originating in the DevOps community provide a means to automatically deploy application components on top of the Cloud resources provisioned before. The DevOps community also publicly offers reusable artifacts to be used for the deployment of particular application components. In addition, (iii) custom scripts (e.g., Unix shell scripts) may be implemented to manage the application during runtime (e.g., adding new users).
However, it is hard to combine these building blocks because the invocation mechanisms of Web services/APIs, scripts, and other plans involved in these automated processes differ significantly from each other and the majority of them is not standards-based (Breitenbücher et al., 2013). The main goal of our work is to address this deficit by creating a management bus that provides a unified invocation interface hiding all the technical details of the employed management technologies. This interface is used by management plans implementing the logic required to automate a particular management task. The main contributions of our work are outlined in the following. We present:
- •
Concepts for unified invocation of different kinds of scripts (e.g., used for deployment) and different APIs (e.g., used for provisioning).
- •
Architecture and prototype of a unified operation invocation bus and interface to be used by management plans based on the Topology and Orchestration Specification for Cloud Application (TOSCA) (OASIS, 2013).
- •
Architecture and prototype of an independent management component to seamlessly integrate different script-centric automation approaches using a unified RESTful API.
- •
An evaluation based on an end-to-end open source toolchain to show that plans get simpler and the number of specific “wrappers” used for invoking certain scripts and services are reduced.
This work is an extension of our previous research (Wettinger et al., 2014) presented and published at the International Conference on Cloud Computing and Services Science (CLOSER). In order to set the context of our work appropriately, we recap our previous research and present our extensions in Section 6. The remaining of this paper is structured as follows: Section 2 outlines the currently existing issues and limitations we address in our work. We present TOSCA as an emerging standard for managing Cloud applications in Section 3 because major parts of our work is based on it. Section 4 discusses the notion of a management plan and the orchestration of management operations using plans. Our concepts and implementations regarding the unified invocation approach are presented in Section 5 and Section 6, followed by an evaluation of this approach in Section 7. Finally, we discuss some related work in Section 8 and conclude this paper in Section 9.