Cloud Orchestration Features: Are Tools Fit for Purpose? Daniel Baur, Daniel Seybold, Frank Griesinger, Athanasios Tsitsipas, Christopher B. Hauser, Jorg¨ Domaschka Institute of Information Resource Management University of Ulm, Germany Email: ffirstname.lastname,[email protected] Abstract—Even though the cloud era has begun almost one based on objective criteria. We also provide a guideline on decade ago, many problems of the first hour are still around. how to grade tools according to the features. (ii) We identify Vendor lock-in and poor tool support hinder users from taking tools that promise to realise some or multiple of the above full advantage of main cloud features: dynamic and scale. This mentioned features. (iii) We rate three tools according to our has given rise to tools that target the seamless management and feature list. orchestration of cloud applications. All these tools promise similar capabilities and are barely distinguishable what makes it hard Based on our feature extraction, it becomes possible to to select the right tool. In this paper, we objectively investigate compare existing and upcoming orchestration tools: What is required and desired features of such tools and give a definition of more, the identified lack of supported features shall drive future them. We then select three open-source tools (Brooklyn, Cloudify, Stratos) and compare them according to the features they support research and development with respect to cloud orchestration. using our experience gained from deploying and operating a The remainder of this document is structured as follows: standard three-tier application. This exercise leads to a fine- Section II introduces the terminology of the document as well grained feature list that enables the comparison of such tools as the methodology of our approach. Section III introduces based on objective criteria as well as a rating of three popular background and basic capabilities of the tools. Section IV cloud orchestration tools. In addition, it leads to the insight that introduces the feature list and does the comparison for each the tools are on the right track, but that further development introduced feature. Section V presents the comparison results and particularly research is necessary to satisfy all demands. from applying the list in tabular I. Section VI discusses related work before we conclude. I. INTRODUCTION The last decade has been dominated by the Cloud in both II. BACKGROUND research and industry. Nevertheless, many problems have been In the following, we briefly introduce the terminology around since the beginning of the cloud era and are sub- that we use throughout the document and further classify the stantially hindering the move forward. These include vendor methodology of our comparison. lock-in, the incomparability of cloud providers with respect to performance per price, the weak adoption of cloud standards from the providers, etc. A. Terminology Particularly, researchers from domains that make use of Even though more advanced terminologies have been pub- clouds such as software engineering and data mining, but lished (e.g. [1]), we follow the well-known NIST standard [2] also software architects and DevOps teams need robust and defining the three service models IaaS, PaaS, and SaaS. powerful mechanisms to bring their applications and inno- vations to the Cloud—ideally to many cloud providers. In We define (cloud) application as a possibly distributed order to perform evaluations and test the elasticity of their application consisting of multiple interlinked application com- application, these users need to be able to seamlessly change ponents. For illustration consider a blog application B that may the distribution of their application across multiple cloud consist of the three components load balancer lb, application providers. They also have to be able to quickly change the server together with the business logic as, and a database db. scaling factor of individual components. Similar considerations hold for start-ups whose demands change with the growth of We depict cloud orchestration tool, as a software compo- the business. nent that manages the complete lifecycle of a cloud application. It therefore needs to fulfil the following criteria: (1) appli- In order to satisfy these demands, a powerful and reliable cation specification (definition); (2) deployment of specified cloud orchestration and operation platform is needed. Indeed, applications: the tool has to acquire virtual machines and then there are multiple commercial and open-source tools available distribute component instances over them; (3) collection of that promise to solve above mentioned issues. Yet, it is hard to monitoring data from deployed instances. This data further has find a visible distinguishing factor. Also, there are barely any to be consolidated and aggregated and provided to the opera- sources available that report on the success of using these tools. tors. (4) If application management shall be (semi-)automatic, This document aims at closing this information gap by the the tool has to allow the definition of rules that capture when following contributions: (i) We establish a fine-grained feature to execute which management task (e.g. scaling). We therefore list that enables the comparison of such orchestration tools explicitly exclude pure deployment tools like Chef. B. Methodology and other configurations are represented in a Stratos specific JSON format. For the deployment itself, it solely relies on While the primary goal of this document is to present a feature the DevOps tool Puppet. The application itself is subsequent list that helps rating cloud development tools a secondary cloned from a Git repository. Stratos is installed as one central goal is to show its applicability to existing software tools. controller and in all virtual machines by having a virtual For this purpose we select three tools fulfilling the above 1 2 machine image prepared with the necessary software (Stratos mentioned four criteria: Apache Brooklyn , Cloudify , and and Puppet agents) installed. Apache Stratos3. For the evaluation we install the tools in our local data IV. FEATURES AND COMPARISON centre and apply the defined features. As a sample application we select a three-tier application consisting of NGINX as a In this section we perform the actual comparison. Each of load balancer, Node.js as an application server running the the following two sections introduces a set of features. Sec- Ghost blogging application, and PostgreSQL as a database tion IV-A addresses cloud-related aspects and Section IV-B management system. The used application descriptions are considers application-related features. 4 available on Github . In the individual sections, we introduce the features of the set and for each of them, (i) define the feature in detail III. INTRODUCTION TO TOOLS and argue why it is desirable. In case sub-features exist for a feature, they are introduced as well (highlighted in italics). All three selected tools make use of third party IaaS platforms Moreover, we (ii) discuss to what extend each feature and all for running applications and all of them offer a PaaS-like in- its sub-features are actually supported by each of the three terface to operators. Below we introduce the tools in particular tools. with respect to their terminology and define the versions used for the evaluation. As a rule of thumb, we used the latest stable version available at the time writing this document. A. Cloud Feature Set Apache Brooklyn is compared using milestone release 0.7.0- The Cloud Feature Set relates to the cloud infrastructure. M2-incubating. Brooklyn’s application description is based on Hence, its features focus on supported deployment across blueprints written in a domain specific language (DSL) in multiple cloud providers and levels. YAML format. A blueprint contains global properties (e.g. 1) Multi-Cloud Support Feature: Supporting multiple name, cloud provider configuration) as well as a services cloud providers is one of the most crucial features for cloud block defining application components. The definition of the application management tools, as it allows the selection of the components is split into abstract types and entities. The type best matching cloud offer for an application from a diverse captures the structure for entities such as defining the proper- offering landscape. Cloud providers often differ from each ties and interfaces. The entities refer to those types and provide other regarding their API. This causes the user to suffer from the concrete configuration. Each type is linked to a Java a vendor lock-in once he depends on the native API of a cloud implementation. Besides deployment, Brooklyn also supports provider. For that reason cloud orchestration tools should offer a monitoring interface and elastic adaptation at runtime. a cloud abstraction layer which hides differences and avoids Cloudify by GigaSpaces Technologies is offered in a free open- the need for provider-specific customisation thus removing the source edition and a commercial Pro edition. Our comparison vendor lock-in. is based on the open-source edition version 3.2. Cloudify Apache Brooklyn Support: Brooklyn uses Apache uses a TOSCA-aligned modelling language for describing jclouds as cloud abstraction layer and therefore supports many the topology of the application which is then deployed to public and private cloud providers. allocated virtual machines in the cloud environment. TOSCA- like, Cloudify splits the blueprint in a type and template Cloudify Support: Cloudify comes with plugins sup- definition. Types define abstract reusable entities and are to porting AWS, Openstack and VMWare vCloud. It also offers a be referenced by templates. The types therefore define the contributed plugin for Apache Cloudstack and two commercial structure of the template, by e.g. defining the properties that plugins (Pro version) for VMWare vSphere and SoftLayer. a template can have/must provide. The template then provides Nevertheless, Cloudify does not support an abstraction layer the concrete values. This mechanism is used for nodes as well and each model needs to explicitly reference cloud provider as for relationships.