9th International Workshop on Science Gateways (IWSG 2017), 19-21 June 2017 Towards Cloud Application Description Templates Supporting Quality of Service Gabriele Pierantoni, Tamas Kiss, Gabor Terstyanszky University of Westminster London, UK pierang@westminster.ac.uk, {t.kiss, g.z.terstyanszky}@westminster.ac.uk Abstract—Typical scientific, industrial and public sector utilization in order to serve a variable number of customers. applications require resource scalability and efficient resource However, the dynamic and intelligent utilization of cloud utilization in order to serve a variable number of customers. Cloud infrastructure resources from the perspective of cloud computing provides an ideal solution to support such applications. applications is not trivial. Although there have been several However, the dynamic and intelligent utilization of cloud efforts to support the intelligent and coordinated deployment, infrastructure resources from the perspective of cloud applications is not trivial. Although there have been several efforts and to a smaller extent also the run-time orchestration of cloud to support the intelligent and coordinated deployment, and to a applications, no comprehensive solution has emerged until now smaller extent also the run-time orchestration of cloud that could be applied in large scale near operational level applications, no comprehensive solution has emerged until now industry trials. that successfully leverages large scale near operational levels and ease of use. COLA is a European research project to provide a The migration to IaaS platform is also slowed down by the reference implementation of a generic and pluggable framework intrinsic complexity required to describe the correlated services that supports the optimal and secure deployment and run-time that compose an application, the QoS that describe its execution orchestration of cloud applications. Such applications can then be and the procedures to deploy, undeploy and migrate embedded into workflows or science gateway frameworks to applications in different IaaS platforms. When faced with such support complex application scenarios from user-friendly complicated solutions, users may decide to procrastinate or interfaces. A specific aspect of the cloud orchestration framework refuse to use IaaS solutions if they are not properly supported. developed by COLA is the ability to describe complex application This problem bears some conceptual similarities to those faced architectures incorporating several services. Besides the description of service components, the framework will also in large scale systems, included Science Gateways and support the definition of various Quality of Service (QoS) Workflow systems in optimally exposing information to its parameters related to performance, economic viability and different users at runtime[4][5]. However the current problem security. This paper concentrates on this latter aspect analysing focuses on the description of “what is an application made of” how such application description templates can be developed (e.g. the graph of its services and how to execute them given a based on existing standards and technologies. set of QoS parameters) rather “what is an application doing” as investigated in the Science Gateway and Workflow problem. Keywords — Cloud Orchestration, Cloud Application Topologies, TOSCA, COLA A new European funded research project, Cloud Orchestration at the Level of Application (COLA) [3] aims at addressing these I. INTRODUCTION difficulties to foster the adoption of cloud computing services. The COLA project will provide a reference implementation of Cloud Computing has successfully and steadily addressed a generic and pluggable framework that supports the optimal issues of increasing complexity of IT management[1][2] and and secure deployment and run-time orchestration of cloud control of its costs for the last decade. However, at each step, applications. Such applications can then be embedded into new challenges must be solved. Nowadays, the use of workflows or science gateway frameworks to support complex Infrastructure as a Service (IaaS) layers to externalize the application scenarios from user-friendly interfaces. A specific management and decrease the relative costs of the infrastructure aspect of the cloud orchestration framework developed by is quite common but its adoption still raises difficulties of both COLA is the ability to describe complex application technical and economic nature. Although it could offer architectures incorporating several services. Besides the significant savings, the move to Cloud IaaS has been somehow description of service components, the framework will also slower and more cautious in certain fields due to limited support the definition of various Quality of Service (QoS) application-level flexibility and security concerns. parameters related to performance, economic viability and Typical applications from the scientific, industrial and public security. sector require resource scalability and efficient resource This work was funded by the COLA Cloud Orchestration at the level of Applications Project No. 731574 project. 9th International Workshop on Science Gateways (IWSG 2017), 19-21 June 2017 In order to assess the validity of its solutions, COLA will test in the form of a generic framework where multiple technology the applicability of the developed infrastructure in implementations can be plugged-in and applied on demand. demonstrators and twenty further proof of concept case studies from four distinct application areas that include SMEs and the III. COLA ARCHITECTURE public sector. COLA use cases incorporate social media data analytics for local governments, simulation-based evacuation planning, data-intensive web applications, and simulation solutions for manufacturing and engineering [10]. This paper focuses on the proposed application description template concept of the COLA project. The rest of the paper is structured as follows: Section II details the objectives of the project, Section III describes the overall architecture of the COLA, Section IV describes the state of the art in the languages used to describe applications, Section V describes the criteria under which TOSCA was selected, Section VI, outlines how the TOSCA language will be used and extended in COLA, finally, Section VII covers conclusions and future work. II. OBJECTIVES OF THE COLA PROJECT Figure 1, The COLA Project Architecture On the resource provision side, Infrastructure as a Service (IaaS) clouds can scale up or down on demand; however, the In order to address the above objectives, COLA defined a dynamic and intelligent utilisation of such scalability from the generic architecture to cover all layers of application level perspective of cloud applications is not trivial. Many legacy orchestration. The overall framework (see Figure 1), called applications have been migrated to cloud infrastructures that MiCADO, is generic in the sense that it does not dictate the only consume and run on a predefined static set of resources. actual implementation of its components. The identified layers More cloud-aware applications have also been developed that and their desired functionality can be implemented in various offer dynamic scalability based on the demands of user numbers ways using different technologies and services that in many or application characteristics. However, these applications have occasions already exist. The layers of the generic MiCADO typically been custom developed requiring significant time and architecture (from top to bottom), are as follows: low level cloud computing expertise to implement. On the other Application Layer contains actual application code and data to hand, typical application patterns can be relatively easily make an incarnation of an application definition. For example, identified that support a large number of similar applications this layer could populate database with initial data, and and can use rather similar underlying mechanisms from configure HTTP server with look and feel and application logic. dynamic clouds. This layer of the architecture will be represented by the COLA The overall objective of the COLA project is to define a generic SME and public sector demonstrators that will be implemented pluggable framework, called MiCADO (Microservices-based using the developed MiCADO tools. Cloud Application-level Dynamic Orchestrator) [4] that Application definition layer is where software components supports optimal and secure deployment and run-time and their requirements (both infrastructure and security orchestration of cloud applications. The MiCADO framework specifications) as well as their interconnectivity are defined will be able connect to multiple cloud middleware (e.g. EC2, using application descriptions. As the infrastructure is agnostic CloudSigma, OpenStack, OpenNebula, etc.) or generic cloud to the actual application using it, the application template can access layers (e.g. CloudBroker Platform) via well-defined be shared with any application that requires such an standardised interfaces to avoid dependence on one particular environment. At this level the COLA project investigates and cloud technology. MiCADO will also be expressed with a set develops generic and widely applicable application templates of interfaces that support the integration of MiCADO enabled that can be reused by application developers in multiple use- applications to workflow systems and science gateway case scenarios, significantly speeding up the development frameworks to provide more convenient access for end-users. process. The guidelines driving the design of the Application COLA will build on existing low level cloud container Description Template are to support re-usability, to foster the technologies (e.g. Docker[5], Swarm[6], Consul[7]), exchanging and sharing of descriptions among similar management and orchestration solutions (e.g. Chef, Puppet, applications and, finally, to allow different profile of users to Occopus[8]), and existing standards, such as, TOSCA [9]. focus on the facet they are most interested in allowing the COLA will provide the missing link between existing non cloud incremental definition of the entire application. aware applications and the dynamic capabilities of IaaS Clouds Orchestration layer is divided into four sub-layers. Coordination interface API provides access to orchestration 9th International Workshop on Science Gateways (IWSG 2017), 19-21 June 2017 control and decouples the orchestration layer from the application definition. Microservices discovery and execution layer manages the execution of microservices and keeps track of services running. Microservices coordination logic layer gathers and analyses information on the current performances of the cloud execution environment. Cloud interface API offers an abstraction layer to cloud access. Cloud interface layer provides means to launch and shut down cloud instances. Finally, Cloud infrastructure layer contains cloud instances as provided by IaaS cloud providers. The rest of this paper concentrates on the Application definition layer of MiCADO. Figure 2, Application, Service and Implementation Templates IV. APPLICATION DESCRIPTION A fundamental aspect of COLA and its success is to allow users The problem of application description is fundamental in Cloud to define applications in a simple, reusable and flexible fashion Computing and a large body of work has been produced both in and, at the same time, to allow the definition of Quality of the Academia and the Industry. One of the first tasks of the Service (QoS) terms with which the applications must be COLA project has been to assess various solutions and the executed. The application description language should also be following, either technology dependent or independent options capable of supporting the description of security and other have been considered. policies. Additionally, the applications description language should be supported by tools to be easily written and A. Amazon Machine Image Template understood, to be shared and queried in repositories and Amazon uses Amazon Machine Image (AMI) template [11] to marketplaces, and to be either directly understood by cloud describe all information required to launch an Amazon EC2 orchestrator components or be translated easily into their own instance. An AMI template includes: root volume for the native language. instance, launch permissions that control which AWS accounts can use the AMI, and block device mapping that specifies the To support efficient orchestration of application execution on volumes to attach to the instance when it is launched. There are the Cloud COLA elaborates the concept of application template three AMI templates: base AMI template that contains only the to support application description at three levels: architecture, OS image, foundational AMI template that includes elements service, and implementation. The architecture level manages of a stack that change infrequently, and, full stack AMI template architectures that can be used by different applications in that contains all elements of the stack. business, industry and public sector. Application templates describe these architectures specifying their service types, Amazon CloudFormation[12] supports development, relations, and requirements. The service types are high-level deployment and running of applications on the Amazon cloud. services, for example business logic, presentation logic, data The applications are described by the AWS CloudFormation service, etc. The service level identifies particular types of templates that combine AMI templates. The templates are services specified in the application template, for example stored as text files that comply with the JavaScript Object MongoDB, SQL or other database as data service. Service Notation (JSON) or YAML[13]. The templates can be created descriptions must be added to the application template to create and edited in any text editor and can be managed in the source a service template. The implementation level specifies the code IDE. service version needed to run the service, for example MongoDB v3.1, v3.2 etc., and the required service signature. B. Azure Resource Manager Templates Adding this information to the service template developers Microsoft Azure describes resources through Azure Resource create an implementation template. Each application template Manager (ARM) [14]. ARM combines compute, storage and may have multiple service templates, and each of them may network resources and shows them as a single unit that can be have multiple implementation templates, as shown in Figure 2. created, managed and deleted together. ARM templates contain four entities: parameters, variables, resources to be deployed, and outputs to be produced. There are four template scopes. Capacity scope delivers a set of resources in a standard topology that is pre-configured to be in compliance with regulations and policies. Capability scope is focused on deploying and configuring a topology for a given technology. End-to-end solution scope is targeted beyond a single capability, and instead focused on delivering an end to end 9th International Workshop on Science Gateways (IWSG 2017), 19-21 June 2017 solution comprised of multiple capabilities. Finally, solution values for the resource, attributes that describe output values scope manifests itself as a set of one or more capability scoped for the resource, parameters (optional) that denote the templates with solution specific resources, logic, and desired properties of the resources, and output (optional) that denotes state. the output created after running the Heat template, such as the IP address of the server. C. Oracle Virtual Machine Templates ORACLE enables quick configuration and provisioning of F. Juju Charms multi-tier application topologies onto virtualized and cloud Juju [21] [22] is an open source automatic service orchestration environments by capturing the configuration and packaging of management tool that enables deploying, managing, and scaling existing software components as self-contained building blocks software and services on a wide variety of cloud services and known as appliances. These appliances can then be easily servers. It can significantly reduce efforts needed for deploying connected to form application blueprints, called as assemblies and configuring a product's services. Juju utilizes charms to [15]. They are built on Oracle VM Templates that allow simplify deployment and management tasks. A charm is a set deploying a fully configured software stack by offering pre- of scripts that can be written in any language. After a service is installed and pre-configured software images. The Template deployed, Juju can define relationships between services and contains the virtual machine configuration information, and expose some services to the outside world. Charms encapsulate virtual disks that contain the operating system and any application configurations, define how services are deployed, application software. These components are packaged together how they connect to other services, and how they are scaled. as an Oracle VM Template file according to the industry- Charms define how services integrate, and how their service standard Open Virtualization Format (OVF). ORACLE offers units react to events in the distributed environment, as developers the Oracle Virtual Assembly Builder (OVAB) [16] orchestrated by Juju. Charms usually include all the intelligence to support customisation and provisioning of complex needed to scale a service horizontally by adding machines to the enterprise applications with no manual intervention onto cluster, preserving relationships with all of the services that virtualized and cloud environments. depend on that service. This enables developers to build and scale up and down the service on the cloud. D. Chef recipes and cookbooks Chef [17] [18] is open source cloud orchestration tool that G. TOSCA supports integration with cloud-based platforms. It launches An OASIS technical committee [23], containing industrial and maintains servers, and manages clients that run on nodes, partners, service providers and research organizations has which can be physical or virtual machines. This client performs developed the TOSCA (Topology and Orchestration the automation tasks the specific node requires. The nodes Specification for Cloud Applications) Language Specification register at a server, which then provides recipes defining these [9], [24], [25] [26] as an interface interoperability standard [12]. automation tasks and assigns roles. Cookbooks are used to Its main goal is to enable the creation of portable cloud organize related recipes, which are basically Ruby scripts, and applications and the automation of their deployment and supporting resources. Roles contain lists of recipes, which are management. In order to achieve this goal, TOSCA focuses on then executed by the Chef client upon retrieval from the server three goals: Automated Application Deployment and leading to the desired configuration. management: is achieved by requiring developers to define an Chef uses a pure-Ruby, domain-specific language (DSL) to abstract topology of a complex application and to create plans describe system configuration and it explicitly describes how to describing its deployment and management. Portability of deploy and connect cloud application components. Application Descriptions and their management (but not the actual portability of the applications themselves): TOSCA E. Heat Orschestration Templates provides a standardized way to describe the topology of multi- Heat [19] [20] is a pattern-based orchestration mechanism component applications and it addresses management developed by OpenStack. It provides a template-based portability by relying on the portability of workflow languages orchestration for describing a cloud application by executing used to describe deployment and management plans. Finally, appropriate OpenStack API calls that generate running cloud Interoperability and reusability of components: TOSCA applications. The software integrates other core components of aims at describing the components of complex cloud OpenStack into a one-file template system. The templates allow applications in an interoperable and reusable way [27] [28] for the creation of most OpenStack resource types as well as [29]. The TOSCA language specification is now based on more advanced functionality such as instance high availability, YAML [30] [31] and it allows the description of topologies, instance auto-scaling, and nested stacks. These templates, nodes and relationships at three different levels of abstractions: called Heat Orchestration Templates (HOT), are native to Heat Types: akin to an Abstract class in Object Oriented and are expressed in YAML. These templates consist of: Languages, Templates: akin to a Concrete class in Object resources (mandatory fields) which are the OpenStack objects Oriented Languages and, finally, Instances: akin to an instance that must be created, like server, volume, object storage, and of a class in Object Oriented Languages. network resources. Each resource consists of references that are used to create nested stacks, properties that describe input 9th International Workshop on Science Gateways (IWSG 2017), 19-21 June 2017 The combination of these three levels of abstraction supports VI. EXTENDING TOSCA TO MEET COLA REQUIREMENTS re-usability of descriptions and offers a flexible and expressive TOSCA is a highly flexible language specification and it is syntax for the definition of application templates at different already successfully employed in various cloud-based level of granularity. Such an approach, also supports initiatives. Its adoption in COLA is promising for various implementation where profiles can be automatically completed reasons. to ease the burden of complete specifications [26]. First, COLA’s overall architecture (see Figure 1) is divided into V. SELECTION OF APPLICATION DESCRIPTION APPROACH applications, services and implementations that can be intuitively mapped into the TOSCA specifications of templates, The decision on which approach would be ideal to meet nodes and relationships (see Figure 2) as detailed in Figure 3. COLA’s requirements was based on a comprehensive and Each of the COLA layers can be defined as a TOSCA Topology multi-dimensional analysis to weight strengths and weaknesses Template (a graph of Nodes and Relationship Templates) of each solution. Such an analysis showed that TOSCA would enriched by level-specific policies. At the lowest level, be an ideal candidate for COLA for the following reasons: implementation plans are detailed either as scripts and/or Basic Properties that cover the support for generic workflows. This approach allows for reusability of application functionalities such as portability, scalability and possible descriptions as these descriptions (and parts thereof) that are implementation characteristics and constraints such as the common (or have significant overlap) of different applications packaging of installation artefacts and the availability of can be shared and individually finalized. This process can also examples and tutorials. TOSCA offers support for generic be replicated across the different layers by deriving and functionalities (portability, scalability, etc.) suitable for the incrementally defining the service topologies at each level. project, it offers the packaging of installation artefacts and At the same time, TOSCA can be extended with the definitions supports a large variety of installation methodologies that vary of policies (e.g. to define scale-up and scale-down profiles at from simple scripts to complex workflows. Furthermore and run time, redundancy approaches, security and trust) at the quite importantly, TOSCA is an accepted standard, it is Application and Service layers that will be used to define the supported by a strong and growing community, and there is implementation parameters at the lowest levels. ample literature of several and successful attempts of its usage by the research community. The two latter characteristics combined allow to implement information hiding strategies that diversify the contribution of Entities and Storage that cover the capacity of the various each user profile to what is necessary to be decided at each solutions to describe the individual components and the whole level, leaving all other information to be inferred by templates application, their relationships and their overall design. This at the upper level of automatic definition driven by policies. category also covers the support to publish, store query and share application description profiles. TOSCA’s philosophy is From a programmatic point of view, TOSCA also offers two very similar and highly compatible with COLA’s three layered points of great interest to COLA: the possibility to define the concept to describe applications, their components, their implementation plan both as scripts and as workflows thus relationships and generic templates. TOSCA also supports the offering solutions at the required level of complexity, and, the possibility to publish, discover and share application support to two different execution modes: imperative and description templates. declarative (one where the exact implementation steps are QoS parameters that covers the possibility (if not explicitly the specified, the other where the result is defined and the capacity) of expressing Quality of Service parameters such as implementation can be chosen among a certain range of elasticity, scalability, and security. TOSCA does not directly or solutions). explicitly support QoS parameters but it is flexible and generic Finally, TOSCA is being actively used both in the academic and enough to allow them to be described as policies that will be industrial worlds and therefore offers not only a vast experience later interpreted to other components of the MICADO from which the COLA participants can greatly benefit but also architecture. a variety of implementations that can be directly used to provide Application execution that covers the support for the execution inspiration to COLA. Among these, the most promising are: of the applications. TOSCA per se is a language specification OPENTosca, an open source implementation of TOSCA and so it does not directly provide runtime or container support but TOSCAMart [27], a place to share Application Descriptions, there are implementations that do so (as an example Winery [35], a modelling tool to create TOSCA profiles, and OPENTosca [32], [33] and [34]). Vinotek [36], a portal for the provision of Cloud applications As a further argument to select TOSCA is its interoperability. on demand. Using a combination of these tools will allow to Even today many cloud orchestration tools are able to manage share Applications Templates and also to edit them through TOSCA based application/service descriptions and their dedicated GUIs in the same fashion as an IDE. number is increasing every year. Selecting a TOSCA based approach to specify applications/services will improve the possibility to share description of COLA applications. 9th International Workshop on Science Gateways (IWSG 2017), 19-21 June 2017 International, p. 12, 2014. [11] “Learn Template Basics - AWS CloudFormation.” [Online]. Available: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/gett ingstarted.templatebasics.html. [Accessed: 20-Feb-2017]. [12] “AWS CloudFormation - Infrastructure as Code & AWS Resource Provisioning.” [Online]. Available: https://aws.amazon.com/cloudformation/. [Accessed: 30-Mar-2017]. [13] “The Official YAML Web Site.” . [14] “Microsoft Azure Essentials Azure Web Apps for Developers | Microsoft Press Store.” . [15] Kai Yu, “Design and Implement a SelfService Enabled Private Cloud with Oracle Enterprise Manager 12c.” . [16] “Oracle Fusion Middleware.” [17] “Chef - Automate IT Infrastructure | Chef.” [Online]. Available: https://www.chef.io/chef/. [Accessed: 29-Mar-2017]. [18] M. Pfeiffer, “Chef Server on the AWS Cloud: Quick Start Reference Deployment,” 2015. Figure 3, Extending TOSCA in the COLA project [19] R. Mateescu, “OpenStack Heat – Overview.” [20] “Heat - OpenStack.” [Online]. Available: https://wiki.openstack.org/wiki/Heat. [Accessed: 29-Mar-2017]. VII. CONCLUSION AND FUTURE WORK [21] “Juju | Cloud | Ubuntu.” [Online]. Available: COLA is in its infancy at the moment. The project started in https://www.ubuntu.com/cloud/juju. [Accessed: 29-Mar-2017]. [22] J. Baker and U. S. Team, “Service Orchestration for Cloud Environments January 2017, and a few preliminary results have already been with Juju,” 2012. achieved. A survey of application description languages has [23] OASIS, “OASIS Topology and Orchestration Specification for Cloud clearly highlighted TOSCA as the best approach for COLA and, Applications (TOSCA) TC,” Website, 2014. [Online]. Available: on the implementation side, first prototypes of MiCADO have https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca. [Accessed: 15-Feb-2017]. shown the possibility to rapidly scale up and down deployment [24] “tosca-primer-v1.0.” of a test application (data-avenue [37], a data transfer suite). In [25] A. Brogi, J. Soldani, and P. Wang, “TOSCA in a nutshell: Promises and the current prototype, the scaling policies have not been Perspectives.” described in TOSCA but rather with the local native language [26] P. Hirmer, U. Breitenbücher, T. Binz, and F. Leymann, “Automatic Topology Completion of TOSCA-based Cloud Applications.” of the Cloud orchestrator tool, Occopus, applied. The definition [27] J. Soldani, T. Binz, U. Breitenbücher, F. Leymann, and A. Brogi, of such policies in TOSCA in such a way to be understandable “ToscaMart: A method for adapting and reusing cloud applications,” J. by MiCADO is one of the next steps of the project. Syst. Softw., vol. 113, pp. 395–406, 2016. [28] J. Soldani, T. Binz, U. Breitenbücher, F. Leymann, and A. Brogi, References “TOSCA-MART: A Method for Adapting and Reusing Cloud Applications TOSCA-MART: A Method for Adapting and Reusing [1] D. R. Avresky, M. Diaz, A. Bode, B. Ciciani, and E. Dekel, Eds., Cloud Cloud Applications *,” 2015. Computing, vol. 34. Berlin, Heidelberg: Springer Berlin Heidelberg, [29] A. Brogi and J. Soldani, “Reusing cloud-based services with TOSCA *.” 2010. [30] “TOSCA Simple Profile in YAML Version 1.0.” [Online]. Available: [2] F. Leymann, Cloud Computing. 2011. http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile- [3] “About – COLA Project – Cloud Orchestration at the Level of YAML/v1.0/csd03/TOSCA-Simple-Profile-YAML-v1.0-csd03.html. Application.” [Online]. Available: http://www.project-cola.eu/cola- [Accessed: 15-Feb-2017]. project/. [Accessed: 27-Mar-2017]. [31] W. Draft, “TOSCA Simple Profile in YAML Version 1.0,” 2014. [4] H. Visti, T. Kiss, G. Terstyanszky, G. Gesmier, and S. Winter, “MiCADO [Online]. Available: http://docs.oasis-open.org/tosca/TOSCA-Simple- – Towards a microservice-based cloud application-level dynamic Profile-YAML/v1.0/csprd01/TOSCA-Simple-Profile-YAML-v1.0- orchestrator,” Jan. 2016. csprd01.html. [Accessed: 14-Feb-2017]. [5] “Docker - Build, Ship, and Run Any App, Anywhere.” [Online]. [32] “OpenTOSCA Ecosystem.” . Available: https://www.docker.com/. [Accessed: 30-Mar-2017]. [33] “OpenTOSCA Container – Architecture.” [Online]. Available: [6] “Docker Swarm overview - Docker Documentation.” [Online]. Available: http://www.iaas.uni- https://docs.docker.com/swarm/overview/. [Accessed: 30-Mar-2017]. stuttgart.de/OpenTOSCA/container_architecture.php. [Accessed: 20- [7] “Consul Architecture - Consul by HashiCorp.” [Online]. Available: Feb-2017]. https://www.consul.io/docs/internals/architecture.html. [Accessed: 30- [34] T. Binz et al., “OpenTOSCA – A Runtime for TOSCA-based Cloud Mar-2017]. Applications.” [8] “Welcome - Occopus.” [Online]. Available: [35] O. Kopp, T. Binz, U. Breitenbücher, F. Leymann, and U. Breitenb, http://occopus.lpds.sztaki.hu/en_GB/. [Accessed: 29-Mar-2017]. “Winery – A Modeling Tool for TOSCA-based Cloud Applications.” [9] T. Binz, U. Breitenbücher, O. Kopp, and F. Leymann, “TOSCA: Portable [36] U. Breitenbücher, T. Binz, O. Kopp, and F. Leymann, “Vinothek – A Self- Automated Deployment and Management of Cloud Applications,” in Service Portal for TOSCA.” Advanced Web Services, 2014, pp. 527–549. [37] “Welcome - Data Avenue.” [Online]. Available: https://data-avenue.eu/. [10] S. J. E. Taylor, T. Kiss, G. Terstyanszky, P. Kacsuk, and N. Fantini, [Accessed: 03-Apr-2017]. “Cloud computing for simulation in manufacturing and engineering: introducing the CloudSME simulation platform,” Proceedings of the 2014 Annual Simulation Symposium. Society for Computer Simulation