Deployment Over Heterogeneous Clouds with TOSCA and CAMP

Deployment over Heterogeneous Clouds with TOSCA and CAMP

Jose Carrasco, Javier Cubo, Ernesto Pimentel and Francisco Duran´ Dept. Lenguajes y Ciencias de la Computacion,´ Universidad de Malaga,´ Malaga,´ Spain

Keywords: Cloud Applications, Cross-cloud, Cross-deployment, Standards, TOSCA, CAMP.

Abstract: Cloud Computing providers offer diverse services and capabilities, which can be used by end-users to com- pose heterogeneous contexts of multiple cloud platforms to deploy their applications, in accordance with the best offered capabilities. However, this is an ideal scenario, since cloud platforms are being conducted in an isolated way by presenting interoperability and portability restrictions. Each provider defines its own API, non-functional requirements, QoS, add-ons, etc., and developers are often locked-in a concrete cloud environment, hampering the integration of heterogeneous provider services to achieve cross-deployment. This work presents an approach to deploy cross-cloud applications by using standardisation efforts of design, management and deployment of cloud applications. Specifically, using mechanisms specified by the TOSCA and CAMP standards, we propose a methodology to describe the topology and distribution of modules of a cloud application and to deploy the inter-connected modules over heterogeneous clouds. We present our prototype TOMAT, which supports the automatic distribution of cloud applications over multiple providers.

1 INTRODUCTION services, non-functional requirements, QoS, add-ons, etc. As a result, cloud developers are often locked-in Cloud Computing (Armbrust et al., 2010) is the re- specific services from some concrete cloud environ- sult of the evolution of different paradigms and tech- ment, complicating the integration of heterogeneous nologies, such as Virtualisation, Client-Server Model, provider services to achieve a cross-deployment of Peer-to-Peer, or Grid-Computing. It has become a cloud applications (Petcu, 2011), and making almost key component in the new Internet, by establishing impossible to consider the possibility of migrating a model for business services that allows a suitable components between different platforms. and on-demand network access to a shared pool of Organizations like IEEE and OASIS have pro- configurable computing resources that can be rapidly posed different approaches to mitigate these issues provisioned (Mell and Grance, 2011). In this model, through the homogenization and normalization of providers expose theirs resources as services through the description and management of cloud applica- a cloud infrastructure. Hence, many providers are of- tions. We find of particular interest two OASIS fering cloud-oriented services, from big companies standards, namely TOSCA (Topology and Orchestra- such as Amazon, Google, or Microsoft, to small play- tion Specification for Cloud Applications) (OASIS, ers. Then, developers may use these cloud resources 2012b) and CAMP (Cloud Application Management to host and deploy the infrastructure and application for Platforms) (OASIS, 2012a). These standards de- modules in specific providers, taking advantage of fine methodologies to describe and wrap the structure the elasticity and scalability of the clouds. In fact, of cloud applications (components and relationships), in an ideal scenario, users could select the services and how they must be orchestrated (using plans) in from several providers whose properties and capabil- a portable way to increase a vendor-neutral ecosys- ities best fit the requirements of every module of the tem. However, although they describe the mecha- application, by enabling a flexible and multiple de- nisms that must be implemented by the clouds to sup- ployment, as addressed in, e.g., (Brogi et al., 2014). port standard-based application deployment and man- Cross-cloud application deployment is a complex agement, they do not have official implementations. task, since cloud platforms are being conducted in Partial support for them is available through, e.g., an isolated way, presenting many interoperability and OpenTOSCA (Binz et al., 2013) and Alien4Cloud1 portability restrictions, and offering similar resources differently. Providers define their own APIs to expose 1Alien4Cloud: http://alien4cloud.github.io/.

170

Carrasco, J., Cubo, J., Pimentel, E. and Durán, F. Deployment over Heterogeneous Clouds with TOSCA and CAMP. In Proceedings of the 6th International Conference on Cloud Computing and Services Science (CLOSER 2016) - Volume 1, pages 170-177 ISBN: 978-989-758-182-3 Copyright c 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

Deployment over Heterogeneous Clouds with TOSCA and CAMP

for TOSCA, and Apache Brooklyn2 for CAMP. solution automatizes the translation between both TOSCA is a good option for representing the standards by using a transformation model, providing topology and orchestration of applications. However, structural and design advantages for the topology de- the management of a possible TOSCA-compliant description using (agnostic) TOSCA, and benefits of the ployment could be a complex task. Since TOSCA run-time management using CAMP. Specifically, we does not enforce specific interfaces for node tem- combine the advantages of TOSCA’s powerful mod- plates, which represent the provider’s resources, the eling language to describe the structure of an appli- topology and orchestration plan may need to be mod- cation as a typed topology graph, in a portable and ified when some module of the application is decided vendor-agnostic way, and simplifying the manage- to be deployed on a different target provider. ment and reusability of services thanks to its topology Even if considering what the standard calls declar- templates and node types, with CAMP’s facilities for ative plans, as we will see in Section 2.1, the TOSCA managing heterogeneous providers’s features in a ho- specification of the topology requires using node tem- mogeneous way thanks to its approach for the unifica- plates for specific providers, what prevents the spec- tion in the interfaces of cloud platforms. Preliminary ification from being agnostic. Moreover, although results related to our proposal were presented in (Car- by using appropriate node templates we may specify rasco et al., 2015). and deploy cross-cloud TOSCA configurations, we The rest of this paper is structured as follows. Sec- need to take into account how providers services are tion 2 presents a brief introduction to TOSCA and managed by TOSCA, and how components are de- CAMP. Section 3 presents the proposal, using exam- ployed and their interactions handled. OpenTOSCA ples to illustrate the approach. We wrap up in Sec- requires each operation in the node types modeling tion 4 by presenting some conclusions and some ideas provider resources to include the necessary mecha- for future development. nisms. Alien4Cloud uses Cloudify3 as cloud service orchestrator for the providers interaction, what allows using a generic node type to model cloud services. However, the implementation artefacts correspond- 2 SOME BACKGROUND ing to the operations of the node templates must be adapted to work with such an orchestrator. Although In this section, we briefly present the TOSCA and with Alien4Cloud the definition of node types is much CAMP standards, mainly focusing on their strengths simpler, the set of target providers is limited to those and limitations. supported by the orchestrator. We are interested in application models in which 2.1 The TOSCA Standard we do not need to lock to a specific vendor, and want to be able to postpone our deployment deci- sion as much as possible, even opening the door to The TOSCA standard (OASIS, 2012b) provides a potential migration of individual components at run- model for the description of cloud applications, the time. Although cross-deployment was not one of corresponding services, and their relationships using the goals of the existing CAMP-compliant solutions, a service topology, as well as the description of pro- they follow a unified API which wraps the inter- cedures to manage services using orchestration pro- face of cloud providers (e.g., Brooklyn uses Apache cesses by using plans. jClouds4). Nevertheless, CAMP lacks of a topology As depicted in Figure 1, in TOSCA, services are specification, which is crucial to maintain the applica- specified through service templates, by using node tion model at run-time, key if monitoring and recon- and relationship templates, which are concrete com- figuration actions are to be performed over the appli- ponents of the application of corresponding node and cation distribution. relationship types. A Node Type expresses the ca- Although both standards present weaknesses, we pabilities, requirements, properties and interfaces of believe they nicely complement each other, and can the services. Relationship Types are used to specify be used together in real scenarios. We propose relationships between the elements of the system by the combined use of TOSCA and CAMP specifi- means of a set of relations, which allow determin- cations and their respective approaches by using a ing the connections and dependencies between com- transformation-based platform-agnostic model. Our ponents, taking into account their properties and interfaces. Type definitions include operations to de- 2Brooklyn: https://brooklyn.apache.org/. scribe their behavior, e.g., a server may define a start 3Cloudify: http://getcloudify.org/. operation to initialize the execution, and another one 4jClouds: http://jclouds.apache.org/. to allow the deployment of applications inside itself.

171 CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

tration plans. The plan specifies the operation calls of components to instantiate the structure of the topology. In the TOSCA standard, the values for the properties of node and relationship templates in a topology template can come from input passed in by users, by automated operations, or by specified default values. A TOSCA-based description is packaged in a container file, called a CSAR (Cloud Service Archive). CSARs have a fix structure to allow portability between providers. To establish a homogeneous environment of clouds for deployment of CSARs, TOSCA defines a set of best practices to adapt the standard to services offered by cloud providers Figure 1: TOSCA Service Template elements. 2.2 The CAMP Standard

The CAMP standard (OASIS, 2012a) focuses on the deployment, management and monitoring of cloud applications, regardless of the used platform. Its main purpose is to allow the interoperability of interfaces of cloud platforms defining a unified API to be implemented by each platform supporting the standard. In such a way, developers and independent platforms could create services and mechanisms to interact with Figure 2: Chat App TOSCA topology (using Winery). other platforms by adapting the CAMP specification and using their interfaces. 1 4 deployment, providing the basis to mitigate the porta- 5 bility/interoperability problems. CAMP specifies 6 80 models for platform, resources, services, sensors and 7 operations. The platform represents the layer at the 8 9 top of the platform under execution, and references 10 form, and the metadata that describe the resources 14 supported by the platform and the extensions by the 15 provider. Resources can be implemented by means of the API provided by the cloud platform with dif- Listing 1: JBoss node template. ferent concepts (assemblies or components). Services are used to interact with the platform, representing the Then, templates specify the concrete features of com- creation and management of resources (e.g., deploy a ponents, e.g., their properties and restrictions. Web application). Following the goal of facilitating Figure 2 shows the TOSCA topology, using Win- the management and monitoring of deployed systems, ery (Kopp et al., 2013), for a very simple Chat Ap- CAMP defines sensors, which through a RESTful in- plication composed by two modules, namely a web- terface give access to different metrics on the status page and a database. We use this example through- of the application components. Operations represent out our paper to illustrate the different aspects of our actions that can be taken on resources. By combining approach. In the example, we suppose we will de- sensors and operations, CAMP proposes the use of ploy the webpage on Amazon AWS and the database policies for self-management: operations depending on SoftLayer. The code in Listing 1 shows the XML on the information collected by sensors. TOSCA description of the node template for the web- As TOSCA, CAMP defines a packaging artifact page corresponding to a JBoss component. for application models and elements for the deploy- In TOSCA templates, we can also specify orches- ment called PDP (Platform Deployment Package).

172 Deployment over Heterogeneous Clouds with TOSCA and CAMP

Topology Description. We consider applications 1 services: composed of several modules or components, 2 - serviceType: org.apache.brooklyn.entity.webapp.jboss. JBoss7Server with relationships and dependencies between 3 name: JBoss Main Web Server them. We propose using TOSCA for the 4 location: aws-ec2:us-west-2 specification of the application’s topology and 5 id: JBossMainWebServer its distribution. This allows us maintaining 6 brooklyn.config: 7 port.http: 80+ the application structure independently of the 8 port.https:3344+ cloud services used along the life-cycle of the application. Listing 2: Brooklyn description of a JBoss Server. Portability and Interoperability. Dealing with a multiple deployment and heterogeneous distribu- An application PDP contains its deployment plan in tion, portability and interoperability problems oc- a YAML file, platform elements used during the life- cur due to restrictions imposed by used services. cycle, and credential files. This description is done Developers may need to adapt their systems (ap- over CAMP’s API to ensure portability. plications, services, components) to the interfaces Although there is no official CAMP implementa- of the specific cloud providers used for deploy- tion, Apache Brooklyn2 supports almost all features ment. By following CAMP’s philosophy, we mit- and concepts in CAMP. Brooklyn is a framework igate this dependency through a common API for modeling, managing and monitoring applications, wrapping and unifying cloud service features and which offers a unified API, and allows the modeling requirements offered by a large number of diverse of application modules and its infrastructure for de- providers. Heterogeneity will be directly dealt ployment and monitoring. Brooklyn’s API is built with by managing cloud services in a homoge- over jClouds, an open source cross-cloud toolkit to neous way. create platform-independent applications, which ensures the interoperability and portability with more Scalability and Elasticity. Our approach considers than 30 different providers. the scalability and elasticity benefits of multiple Brooklyn provides support for deploying applica- providers by using the most appropriate cloud to tions, once the deployment location of each appli- deploy each application module, and giving ac- cation module has been specified, providing support cess to the facilities provided by each of them. for establishing and maintaining the relationships be- Figure 3 presents the overview of our approach tween the different modules. This facility may be to cross-deployment through the combined use of used for performing heterogeneous deployment, us- the TOSCA and CAMP standards. The proposed ing services of multiple providers. We have indeed methodology consists of two main phases. In the first used this facility to partially solving the portability phase, Topology Description, the topology of an ap- and interoperability problems between services, and plication is exhaustively defined using TOSCA (1). to facilitate the complicated deployment in TOSCA. In the second phase, Translation and Deployment, Listing 2 shows the Brooklyn YAML excerpt describ- the application modules are distributed over selected ing a JBoss server for the webpage (corresponding cloud providers using the CAMP-based deployment to the TOSCA template in Listing 1) using a com- strategy implemented in Brooklyn. To solve the in- mon API. As specified in Line 4, the component is re- compatibility problems between the TOSCA-based quested to be deployed on aws-ec2:us-west-2, Ama- XML topology and the CAMP-based YAML deploy- zon’s datacenter at Oregon, US. ment plan, we have modeled and developed a translation process based on an agnostic graph (2). As ex- plained in the coming sections, the graph is built on 3 CROSS-DEPLOYMENT OF an abstraction of the application topology, providing CLOUD APPLICATIONS a representation independent of the specific used de- ployer, Brooklyn in this case. The use of these graphs In this section, we present our proposal for improving also simplifies the translation process from TOSCA to interoperability and reducing portability problems of CAMP, which finally generates the CAMP-compliant heterogeneous clouds. deployment plan expected by Brooklyn (3). Brooklyn is then in charge of deploying the given application, using jClouds to enable provider-independent deploy- 3.1 Overview of our Approach ment, and cross-deployment if required. The main goals and advantages of our approach are:

173 CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

Figure 3: Overview of the methodology for cross-deployment.

3.2 TOSCA-compliant Topology the deployment operations. Our proposal does not need to run these artifacts We use TOSCA to obtain a full description of the ap- though, and therefore, we do not need the required plication by modeling its modules and dependencies. robust logic to infer the distribution information from TOSCA descriptions are composed of components, them. But we instead need a mechanism to clearly which present types, properties, requirements, capa- specify the final provider each of the node templates bilities, and relationships between them. is to be deployed on. TOSCA allows the specification of a detailed ap- TOSCA allows the specification of properties to plication topology using XML files. Although it has specify the way in which applications are going to the advantage of providing the flexibility to design behave, e.g., to achieve specific service level objec- any component that an application may require, the tives. Indeed, the possibility of adding further proper- modification, removal or addition of components in a ties to node templates is one of the main arguments topology may become a cumbersome task. We pro- of TOSCA’s flexibility. We take advantage of this pose the use of graphical tools such as Winery (Kopp possibility and specify the location to which node et al., 2013), from the OpenTOSCA environment, for templates are to be deployed as properties of node these tasks. Winery provides support for the graph- templates. By defining these properties, we get all ical generation of TOSCA-based application topolo- the information we need to generate the correspond- gies and their maintenance. ing CAMP specifications. Note that this flexibility, For describing a topology, TOSCA does not pro- however, involves an even higher complexity in the vide any mechanism to specify the target provider to TOSCA orchestration plan, since the plan must spec- deploy application modules. Instead, NodeTypes de- ify the management of all the properties according to fine an orchestration plan and the implementation ar- the system configuration. tifacts to specify the deployment operations. These Listing 3 shows how the TOSCA XML specifi- artifacts define the specific distribution of the compo- cation of the JBoss node template in Listing 1 has nents implementing the logic to perform the deploy- been extended to specify the location to be deployed ment. at (Line 7). With this specification, it will be deployed We described on Section 1 as the providers to be on Amazon AWS, using Oregon’s clusters. A descrip- used to deploy our components on can be defined tion as the one shown in Listing 2 can now be auto- and replaced on some TOSCA-compliant approaches. matically generated. However, the definition and maintenance of an orchestration plan is a complex and error-prone task. 3.3 TOSCA2CAMP Transformation TOSCA imperative plans have to define each necessary step to deploy and configure the application, tak- CAMP provides support for the deployment over het- ing into account all the properties and requirements of erogeneous clouds, solving interface incompatibili- the providers. TOSCA declarative plans need to add ties through a unified API. By performing a transfor- new implementation artifacts to modify the the oper- mation from TOSCA to CAMP elements, we take ad- ations of node templates. Thus, if we need to change vantage of this capability to deploy TOSCA specifi- the cloud providers on which modules are to be de- cations over multiple cloud providers. ployed, the plan’s operations should be accordingly modified, since the modification of the providers is performed by substituting the artifacts that implement

174 Deployment over Heterogeneous Clouds with TOSCA and CAMP

corresponding agnostic type provides the necessary 1 One important aspect in the correlation between 4 TOSCA and agnostic components is the management 5 of properties (see Section 3.2). By using agnostic ele- 6 80 7 aws-ec2:us-west-2 ments we simplify the generation of CAMP elements 8 to be used in the deployment, unbinding the descrip- 9 tion of TOSCA elements to the heterogeneous APIs 10 used by CAMP implementations. Since each service 11 ponents, it is required to establish a relationship be- 15 tween the TOSCA properties defining the topology, 16 which are not subject to constraints, and CAMP prop- Listing 3: Node Template enriched with Location. erties, which are predefined. E.g., a JBossWebServer in the Brooklyn API allows defining the port http, so it is necessary to find, in the corresponding TOSCA 1 - service: agnostic.service.type.server.JBossServer 2 name: JBoss Main Web Server element definition, the property which specifies that 3 location: aws-ec2:us-west-2 value. Note that this property could be defined in dif- 4 id: JBossMainWebServer ferent ways in the node template. 5 properties: 6 - id: http CAMP API allows a more detailed configuration 7 type: port based on the properties of theirs elements. E.g., the 8 value: 80 port http of a JBoss server in TOSCA can be defined 9 - id: https 10 type: port by means of a plain property (a string), as a TOSCA 11 value: 3344 property 80. However, the equivalent CAMP property could add more informa- Listing 4: Agnostic description of a JBoss server. tion to define a port range, with, e.g., port.http: 80+, where the symbol ‘+’ indicates that the http port is a 3.3.1 Agnostic Graph Generation value equal or greater than 80. See the agnostic representation of the properties http and https in Listing 4 In the translation process, we use an intermediate ag- (Lines 6-11) as obtained from the property port in the nostic graph to abstract system information to get a TOSCA description of the JBoss component in List- technology-independent intermediate representation ing 3 (Line 6). of applications. This representation is independent This mechanism not only establishes the equiva- both from TOSCA and CAMP description types, lence between properties, but also infers and main- what would allow us to reuse the transformation to tains the necessary knowledge about them. Only in such an agnostic graph or the one from it, e.g., to tar- this way we can adapt them to the configuration re- get CAMP providers other than Brooklyn. quired by the services described in CAMP APIs. We The topology of an application is abstracted as de- therefore need to fix the properties permitted in node picted in step (2) in Figure 3. The information in each templates, which will be interpreted and added to the component is included as a node of the graph, without agnostic elements using types. reference to TOSCA elements, and using the edges to During the CAMP deployment plan generation, specify the relationships between them. the process uses the types of these properties to cor- Listing 4 shows a textual representation of the ag- rectly configure the components described in the cor- nostic graph as obtained from the JBoss node tem- responding CAMP APIs. For example, since Brook- plate in Listing 3. lyn knows that http is a property of the port type, to specify this property, we need to add the symbol ‘+’ 3.3.2 Types and Properties to determine the port range. Figure 4 refines Figure 3 to summarize the genera- Service types of agnostic components are represented tion of a JBoss agnostic component. Steps (1) and (2) by technology-independent agnostic identifiers. E.g., represent the translation of the TOSCA JBoss com- agnostic.service.type.server.JBossServer is used to ponent into the agnostic one. Step (3) checks whether type a JBoss server in the definition in Listing 4. Sim- the properties of the node template are permitted in ilar mappings for each concrete TOSCA type into its the properties list expected by the agnostic element. If

175 CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

Figure 4: From TOSCA JBoss to JBoss agnostic component. so, step (4) includes those agnostic properties into the agnostic component; otherwise, they are discarded. 1 services: 2 - serviceType: org.apache.brooklyn.entity.webapp.jboss. 3.3.3 Plan Generation and Deployment JBoss7Server 3 name: JBoss Main Web Server 4 location: aws-ec2:us-west-2 A CAMP YAML plan is generated from the agnostic 5 id: JBossMainWebServer graph, which can then be used for deployment. A plan 6 brooklyn.config: 7 port.http: 80+ is generated by using another transformation, this 8 port.https:3344+ time between the agnostic elements and the CAMP- 9 ... compliant components specifying the component dis- 10 - serviceType: org.apache.brooklyn.entity.database. tribution to be deployed. We use Brooklyn to deploy mysql.MySqlNode 11 id: db CAMP specifications. 12 name: DB HelloWorld Visitors As for the previous transformation, we estab- 13 location: softlayer-seattle lish transformation patterns, which are used to an- 14 ... alyze the graph and to generate the orchestration Listing 5: CAMP-compliant Brooklyn blueprint. plan. For instance, for JBoss servers we map agnostic.service.type.server.JBossServer into org.apache.brooklyn.entity.webapp.jboss.JBoss7Server, and 3.4 Implementation for PostgreSQL we map agnostic.service.type.- sql.PostgreSQL into org.apache.brooklyn.entity.data- Our tool TOMAT (TOSCA sMArt Translator) im- base.postgresql.PostgreSqlNode. plements the transformation process presented in the The management of properties is accomplished by previous sections, providing support for the cross- applying mechanisms similar to the ones described deployment of applications over heterogeneous cross- for the transformation between TOSCA and the ag- clouds. TOMAT allows the transformation of TOSCA nostic types. In this case, a service defined in a con- topologies into (Brooklyn) CAMP specifications. As crete CAMP API, like Brooklyn, specifies the prop- pointed out in Section 3.2, for the deployment to erties supported. For example, although the model- be carried out, TOMAT requires the given TOSCA ing of the agnostic JBoss component supports proper- topology to include the providers’ location. The ties http and https, in the corresponding CAMP API tool is available at https://github.com/kiuby88/tomat. definition only the protocol http is supported, but not Some external libraries are used to process the https. Therefore, https will not be included in the ar- transformation from TOSCA to (Brooklyn) CAMP. tifact in the generated plan. Specifically, to interpret the extended TOSCA topol- Once the CAMP-compliant orchestration plan is ogy description, we use a module from the Open- generated, the distribution will depend on the con- TOSCA container which models the TOSCA topol- crete platform implementing the standard, Brooklyn ogy in Java by means of a customised JAXB. For the generation and visualisation of the agnostic graph, we in our case. 5 6 Listing 5 shows the CAMP-compliant Brooklyn use libraries JGraphT and JGraph, respectively. blueprint for our simple example containing entities corresponding to a JBoss Server and a MySQL, deployed on Amazon (Oregon’s Cluster) and SoftLayer 5JGraphT: http://jgrapht.org/. (Seattle’s Cluster), respectively. 6JGraph: http://www.jgraph.com/.

176 Deployment over Heterogeneous Clouds with TOSCA and CAMP

4 CONCLUDING REMARKS the potential of our intermediate agnostic graph to add support for other CAMP/TOSCA specifications, such 7 We have presented a flexible methodology to deploy as Ubuntu Juju and Alien4Cloud. cross-cloud applications over heterogeneous clouds through orchestration of services from multiple and diverse providers. Our approach is based on trans- ACKNOWLEDGEMENTS formation processes between two major OASIS standards on cloud interoperability, namely TOSCA and This work has been partially supported by EU project CAMP, taking advantage of the benefits of each of FP7-610531 SeaClouds; Spanish MINECO/FEDER them. TOSCA is used to specify the application projects TIN2014-52034-R and TIN2015-67083-R; topology, and CAMP to deploy the application mod- Andalusian Government project P11-TIC-7659; and ules over clouds. Universidad de Malaga,´ Campus de Excelencia Inter- We have proposed, implemented and validated a nacional Andaluc´ıa Tech. translation process from TOSCA-compliant topologies to CAMP-compliant plans, with an intermediate platform-agnostic model that ensures the inde- REFERENCES pendency between technologies while facilitates the adaptation to new ones, being only required the defi- Armbrust, M. et al. (2010). A view of cloud computing. nition of translation rules from the agnostic model to Comm. of ACM, 53(4):50–58. the new technology. We consider this standard-based Binz, T. et al. (2013). OpenTOSCA–a runtime for TOSCA- flexibility provides a value-added to previous initia- based cloud applications. In Service-Oriented Com- tives to mitigate some vendor lock-in issues. puting, pp. 692–695. Springer. We would like to insist on two ideas. The unifi- Brogi, A. et al. (2014). SeaClouds: a European project cation of the interfaces is implicit in the CAMP def- on seamless management of multi-cloud applications. ACM SIGSOFT SEN, 39(1):1–4. inition, as well as the portability and interoperabil- Carrasco et al. (2015). Towards a flexible deployment ity among services of heterogeneous cloud providers. of multi-cloud applications based on TOSCA and Thanks to this, despite the differences in the APIs CAMP. In ESOCC Workshops, vol. 508 of CCIS, pp. of the final cloud providers, end-users see a unified 278–286. Springer. API which allows them the development of portable Kopp, O. et al. (2012). BPMN4TOSCA: A domain-specific and platform-agnostic applications, whose deploy- language to model management plans for composite ment can be distributed over multiple and heteroge- applications. In Business Process Model and Nota- neous clouds. Note also that mechanisms for scal- tion, pp. 38–52. Springer. ability and elasticity supported by cloud providers Kopp, O. et al. (2013). Winery–a modeling tool is still available. For example, the above mapping for TOSCA-based cloud applications. In Service- Oriented Computing, pp. 700–704. Springer. maps Cluster to its corresponding CAMP-compliant (Brooklyn) element. Mell, P. and Grance, T. (2011). The NIST definition of cloud computing. Technical report. Available at Much work remains ahead. Our tool only supports http://dx.doi.org/10.6028/NIST.SP.800-145. the translation and deployment of Java applications OASIS (2012a). CAMP 1.1. Available at http://docs.oasis- (JBoss, Jetty, Tomcat, ...) and MySQL databases. We open.org/camp. are currently working on including other technolo- OASIS (2012b). TOSCA 1.0. Available at http://docs.oasis- gies (like PHP and Node) and on increasing the sup- open.org/tosca. ported database connections. TOSCA has been re- OASIS (2013). Interoperability Demo of OASIS cently working on the use of YAML-based topology TOSCA. https://www.oasis-open.org/events/cloud/ descriptions (OASIS, 2014). We plan to extend our 2013/toscademo. solution to also support the translation process be- OASIS (2014). TOSCA YAML. Available at http:// tween TOSCA YAML and CAMP YAML. Indeed, it docs.oasis-open.org/tosca. would be interesting to consider the inclusion of this Paraiso, F. et al. (2012). A federated multi-cloud PaaS in- transformation into a system like Brooklyn, so that it frastructure. In IEEE CLOUD, pp. 392–399. IEEE. can take TOSCA YAML specifications and directly Petcu, D. (2011). Portability and interoperability between do the deployment. We are currently involved in a clouds: challenges and case study. In Towards a Service-Based Internet, pp. 62–74. Springer. project working on the integration of Alien4Cloud and Brooklyn with such goal. Our current implementation has Brooklyn CAMP as the target technology for the transformation. In the future, we will explore 7Ubuntu Juju: https://github.com/juju/juju-tosca.

177