CYCLONEUnified Deployment and Management of Federated, Multi-Cloud Applications

Unified Deployment and Management
of Federated, Multi-Cloud Applications

Mathias Slawik1, Begüm İlke Zilci2, Yuri Demchenko3, José Ignacio Aznar Baranda4,
Robert Branchat5, Charles Loomis6, Oleg Lodygensky7, Christophe Blanchet8 7Lab. de l’Accelerateur Lin., Universite Paris Sud 11, Orsay, France,
8 Institute of Bioinformatics, Gif-sur-Yvette, France,
12SNET, Technische Universität Berlin, Germany, {mathias.slawik,ilke.zilci}
3 System and Network Engineering, University of Amsterdam, The Netherlands,
4DANA, i2cat Internet Research Center, Barcelona, Spain,
56SixSq Sàrl, Geneva, Switzerland, Email: {rob,cal}

Various Cloud layers have to work in concert in order to manage and deploy complex multi-cloud applications, executing sophisticated workflows for Cloud resource deployment, activation, adjustment, interaction, and monitoring. While there are ample solutions for managing individual Cloud aspects (e.g. network controllers, deployment tools, and application security software), there are no well-integrated suites for managing an entire multi cloud environment with multiple providers and deployment models. This paper presents the CYCLONE architecture that integrates a number of existing solutions to create an open, unified, holistic Cloud management platform for multi-cloud applications, tailored to the needs of research organizations and SMEs. It discusses major challenges in providing a network and security infrastructure for the Intercloud and concludes with the demonstration how the architecture is implemented in a real life bioinformatics use case.

I Introduction

Contemporary Cloud Computing architectures are layered. Basically, a Cloud infrastructure executes a set of virtual machines which are connected by (nowadays virtualized) networks. On these VMs, computing platforms provide abstractions and a unified management of cloud applications, offering many benefits, e.g., scalability, on-demand provisioning and portability. Futher layered cloud models can be found within the NIST Cloud Computing Reference Architecture [1], as well as the Intercloud Architecture Framework (ICAF) [2].

Clouds are managed in a highly automated fashion by a number of common tools, e.g., PaaS platforms, deployment managers, identity and access managers, as well as network controllers. Furthermore, many applications are federated over multiple Clouds, adding to the architecture complexity.

The “Intercloud” is trending: a globally integrated Cloud of Clouds sharing APIs, protocols, and data formats. A proposal to use existing standards and common mechanisms to achieve the “Intercloud Root” was made by Bernstein, et al. in [3]. Our previous work includes the definition of the ICAF in [2], adressing Intercloud issues, as well as defining models and architecture patterns for federated access control within Intercloud environments in [4].

A future Intercloud could incorporate tightly integrated Cloud platforms such as OpenStack111 and the VMWare Software-Defined Data Center222 While these tools provide integrated Cloud management, they fail to deliver open and standardized APIs, protocols, and data formats, and their components are difficult to replace. Furthermore, Intercloud scenarios require cross-cloud (e.g., public-private) interoperability, compatibility, and interchangeability which is currently challenging to implement. Thus, Application Service Providers (ASPs) as well as their customers are constricted in their deployment of well-integrated Cloud solutions, and the Intercloud awaits its implementation in practice.

The CYCLONE project (Complete and Dynamic Multi-cloud Application Management) aims to enhance end-to-end cloud security and facilitates the deployment, management, and use of complex, multi-cloud applications. The project improves existing production-quality tools to offer a software stack based on open standards and APIs. Concrete project tasks are: Network-IaaS integration, common federated authentication, Intercloud brokering and matchmaking, as well as providing PaaS functionality to ASPs (e.g., VM coordination and automated placement). This publication presents the CYCLONE stakeholders and their requirements, a description of the CYCLONE architecture, as well as an evaluation in form of a practical deployment within the bioinformatics sector.

Ii Stakeholders and Requirements

There are four main CYCLONE stakeholders: (1) cloud application service providers will use CYCLONE components to offer diverse functionality to (2) cloud developers and (3) cloud operators to enable them to easily implement, deploy, and manage cloud applications for (4) cloud application end-users. Nine main requirements for CYCLONE components’ functionality are described in the remainder of this chapter, which are pertinent to complex, federated, multi-cloud applications.

Federated identity (R1): Multi-cloud environment security requires a common authentication system where Cloud application end-users can log in to applications using a federated identity.

End-to-end encryption (R2): Common HTTP intermediaries, such as reverse proxies and load balancers, often act as TLS server connection ends, accessing HTTP/TLS plaintext. There has to be an end-to-end encryption (i.e., user agent to origin server) of sensitive HTTP entity bodies.

Distributed logging (R3): Managing multi-cloud applications effectively requires consolidating all event logs of the involved software, i.e., a distributed logging system.

Deployment description (R4): There has to be a method of describing Cloud application deployments, at best supporting scripting, multi-cloud deployment and orchestration, as well as custom application lifecycle hooks.

Management APIs (R5) Any IaaS solution should provide an easy to use, comprehensible, and rich set of management APIs (R5) for computing, storage, and network.

VM marketplace (R6) To allow collaboration between end-users, VM appliance creators and Cloud administrators, the IaaS solution should incorporate a comprehensible VM marketplace.

Network service management platform (R7): As cloud applications have limited network control and visibility, it is challenging to achieve service delivery automation, resource management, and on-demand network connectivity. To implement advanced network services, there has to be a network service management platform, integrated into the employed IaaS offering.

Brokering (R8): In order to support Cloud application developers in finding suitable services in the vast Intercloud, there has to be a service formalization, a service vocabulary, and a brokering component. It should adapt to dynamically changing Intercloud services’ properties.

Matchmaking (R9): There should be automated matchmaking of Intercloud services properties to cloud operator requirements in order to guide service assessment and selection.

Iii Related Work

This chapter briefly presents the work related to CYCLONE, divided into areas pertinent to different CYCLONE components - in the order of the cloud stack, from infrastructure to application.

IaaS platforms. The most prominent IaaS ecosystem is Amazon EC2, a proprietary public Cloud platform. Two strong open source contenders are OpenStack and OpenNebula [5]. However, they encompass a multitude of components whose set-up requires Cloud operators to follow extensive installation guides.

Configuration Management. The most commonly used configuration management tools are and, both Ruby-based. They require the installation of a server and client agents. Juju555 is a notable tool for deploying and managing Cloud services, featuring a high level application model.

Distributed logging. The most widely deployed distributed logging system is syslog, standardized in [6]. Syslog is often used for lower-level logging, e.g., logging of network daemon output. State-of-the art higher-level application logging includes Logging-as-a-Service offerings, such as Loggly666 and Papertrail777, as well as open source stacks, such as the ELK-stack888, which consists of Elasticsearch (persistence), Logstash (logging middleware) and Kibana (logging dashboard).

Software-defined-Networking Software Defined Networking (SDN) enables dedicated SDN controller software to take all network decisions and has recently gained acceptance[7]. SDN eases data centre (DC) network management and enables new networking capabilities, e.g., centralized control, decoupling of network planes, exposing network APIs, and more. While SDN was initially proposed for core networks, IaaS providers are adopting it to allow holistic infrastructure management (IT+Network). The most relevant open source SDN solutions are OpenDayLight999 (ODL), RYU101010, and ONOS111111 ODL is a popular solution supporting many network technologies. Some Cloud research projects, e.g., COSIGN121212 and BEACON131313, are using it as intra-DC network management system. Yet, it is heavily influenced by vendors, had significant changes, lacks clear documentation, and has a very large codebase. RYU is an open source project initiated by NTT. It is easy to start and well documented. There is limited support of different network devices as RYU focuses on OpenFlow141414 (OF). Also, as OF does not support distributed DCs, Cloud federation scenarios are not supported. ONOS, created by ON.lab, is an open source SDN controller focusing on network performance, scalability, and multilayer designs. Despite being first released in December 2014, it seems to be a promising SDN platform.

All major vendors have commercial SDN solutions: Juniper OpenContrail, Cisco Application Centric Infrastructure, HP SDN VAN controller, Brocade SDN controller (formerly Vyatta), as well as the VMware NSX platform.

End-to-end encryption. There are different technologies for securing HTTP entity bodies end-to-end, notably Secure/Multipurpose Internet Mail Extensions (S/MIME) [8], XML Encryption [9] and Signature [10], HTTPSec [11], as well as Secure HTTP (S-HTTP) [12]. In one of our previous publications we analyze them, show the severe deficiencies of these technologies in Cloud environments and create a novel end-to-end HTTP-based encryption protocol, the Trusted Cloud Transfer Protocol (TCTP) [13].

Federated Identity. There are a number of existing federated identity patterns which can be considered state-of-the-art: One of the most comprehensible is the “Claims Based Identity & Access Control”151515 which uses SAML for transmitting security claims between participating parties. Another more recent approach to federated identity is OpenID Connect161616 which defines a “simple identity layer” based on OAuth 2.0171717 and JSON Web Token181818 OpenID Connect is notable for its wide industry adoption, e.g., by Google, Microsoft, and Salesforce, as well as its ongoing adoption by the GSMA to be used worldwide by mobile network operators.

Complex Application Descriptions. CYCLONE performed an analysis of contemporary application models, i.e., SlipStream, CIMI [14], TOSCA [15], OCCI [16] and Compose YML [17]. The model used by SlipStream already supports full multi-cloud application deployments and triggers. The DMTF CIMI model promises the best overall interoperability within the CYCLONE target area. Therefore, CYCLONE will extend it and use it for describing complex, federated, multi-cloud applications. The rationale can be found in [18].

Fig. 1: The Bioinformatics Use Case

Service Matchmaking and Brokering. There are interface description languages, such as WSDL [19], as well as service description languages from the Semantic Web, e.g., OWL-S [20], SAWSDL[21], WSMO [22], and Linked-USDL [23]. Most of the semantic approaches were abandoned, possibly due to missing industry adoption, e.g., OWL-S (2006), SAWSDL (2007), and WSMO (2008). In our previous work [24] we have revealed unresolved challenges while building a Cloud service repository for regular Internet users: business pertinence, tooling simplicity, information reuse, and Cloud service modeling challenges. To adress these issues, we are building the Open Service Compendium (OSC), an open, wiki-like information system featuring a textual DSL, business-pertinent vocabulary, and a brokering component, presented in depth in [25].

In our survey [26], we observe that service matchmaking approaches from the academia have different problem definitions since they consider different service descriptions. Most of the related work addresses only numeric QoS parameters in a complex manner. However, important service selection criteria which are not numeric are not addressed e.g. list typed properties. In the CYCLONE architecture, we consider that service requesters specify the Clouds to use in advance, however the exact deployment actions are triggered in the background. Following the Grozev taxonomy [27], CYCLONE can be classified as a combination of trigger action and directly managed, while keeping the user’s control of the Cloud distribution.

Iv CYCLONE Architecture and Components

The CYCLONE architecture comprises platform, infrastructure, networking, and multi-cloud management software and is presented in Figure 2.

Fig. 2: The CYCLONE components

It is comprised of components for the Cloud stack (OpenNaaS, StratusLab, and SlipStream), as well as for overall multi-cloud management responsibilities (Identity Federation, Distributed Logging, and the Open Service Compendium).

OpenNaaS is a software-defined network controller for the IaaS interconnections. It provides scheduled, dynamic, and flexible network connectivity services with short provisioning times, thus reducing management complexity and bridging the Cloud to end-to-end network services, both intra- and inter-Cloud.

StratusLab provides infrastructure management APIs, comparable to OpenStack and Amazon EC2. It is easy to set up and features a substantially simplified architecture while being suitable for HPC workflows, as it is based on OpenNebula. Apart from compute, storage and network features, it can also be federated with other StratusLab installations. It uses OpenNaaS to manage the routers connecting the StratusLab VM hosts, offering network services to deployed VMs. As it is published as open source, it can be easily extended and integrated with other CYCLONE components.

SlipStream is an open source Cloud application manager. It is used within CYCLONE to deploy Cloud applications onto one or more IaaS Cloud infrastructures and to manage the Cloud resources allocated to the running Cloud applications. SlipStream combines its deployment engine with an “App Store”, “Cloud Service Catalog”, dashboard, and monitoring to provide a complete engineering PaaS supporting DevOps processes. SlipStream supports most public IaaS services and IaaS Cloud distributions, including StratusLab. In the interest of interoperability, SlipStream is gradually moving from its own RESTful API to the standardized CIMI API.

The CYCLONE Identity Federation is based on Keycloak191919, an open source SSO and IDM solution for browser apps and RESTful services. It is built on top of the OAuth 2.0, Open ID Connect, JSON Web Token (JWT) and SAML 2.0 specifications. CYCLONE end-users can use their own identity provider, e.g., EduGAIN, Shibboleth, Facebook, and Google, to log in to CYCLONE services. This also includes, for example, the login of Cloud developers into SlipStream and of Cloud operators into the distributed logging.

The CYCLONE Distributed Logging unifies the log messages of the Cloud stack and multi-cloud management components and offers end-users easy browsing through their logs. It is build upon the ELK logging stack.

The Open Service Compendium describes IaaS solutions which are available for application deployment. It presents Cloud operators the properties of different offerings, as well as a comparison of deployment options and their costs. We strive for SlipStream integration in order to raise the manageability of complex multi-cloud applications.

V Bioinformatics Use Case and evaluation

The first deployment of the CYCLONE architecture will be in a bioinformatics use case as shown in Figure 1, which is described in this section, along with the CYCLONE requirements which are achieved.

Cloud application users from a set of French laboratories use a portal (R6) to select specific Cloud applications for self-service deployment. This portal uses the SlipStream REST interface in order to deploy them on a StratusLab Cloud hosted by CNRS LAL. SlipStream utilizes a rich deployment description (R4) and consumes the StratusLab VM management APIs (R5). Some of the applications are TCTP-enabled to achieve end-to-end encryption (R2). The OpenNaaS CYCLONE network management platform (R7) configures Openflow-based routers used within the infrastructure at CNRS LAL. Applications and most components integrate with the CYCLONE federation provider allowing CNRS end-users to utilize their RENATER (EduGAIN) accounts for federated identity (R1). All relevant components log their output to the CYCLONE distributed logging (R3). Cloud Developers can use the Open Service Compendium for service brokering (R8) and matchmaking (R9), possibly integrated with SlipStream.

Vi Conclusion

This publication introduced the challenges, stakeholders and requirements of cloud application deployment and management in multi-cloud and multi-provider environments. To meet stakeholder requirements and associated challenges we introduce the CYCLONE architecture and demonstrate its benefits within the practical use case of bioinformatics applications. Through the integration and extension of specifically selected tools, we hope to create a simple, capable, and holistic Cloud management solution. In the future, we will further maturate our architecture and tooling to tackle open engineering challenges and further use cases. This should create an alternative to the complex and monolithic Cloud stacks prevalent today. Moreover, we plan to design test cases and document quantitative results to compare our approach to other Cloud stacks especially in the multi-cloud context.


This work is supported by the CYCLONE Horizon 2020 Innovation Action CYCLONE, funded by the European Commission under grant number 644925.


  • [1] NIST, “Cloud Computing Reference Architecture,” 2011. [Online]. Available:
  • [2] Y. Demchenko, C. Ngo, C. d. Laat, J. Rodriguez, L. M. Contreras, J. A. Garcia-Espin, S. Figuerola, G. Landi, and N. Ciulli, “Intercloud Architecture Framework for Heterogeneous Cloud Based Infrastructure Services Provisioning On-Demand,” in WAINA 2013 proceedings.
  • [3] D. Bernstein, E. Ludvigson, K. Sankar, S. Diamond, and M. Morrow, “Blueprint for the Intercloud - Protocols and Formats for Cloud Computing Interoperability,” in 2009 Fourth International Conference on Internet and Web Applications and Services (ICIW 2009), Institute of Electrical and Electronics Engineers, Ed., 2009, pp. 328–336.
  • [4] Y. Demchenko, C. Ngo, C. d. Laat, and C.-K. Lee, “Federated Access Control in Heterogeneous Intercloud Environment: Basic Models and Architecture Patterns,” in Proceedings of IC2E 2014.
  • [5] D. Milojičić, I. M. Llorente, and R. S. Montero, “Opennebula: A Cloud Management Tool,” IEEE Internet Computing, no. 2, pp. 11–14, 2011.
  • [6] R. Gerhards, “The Syslog Protocol: RFC5425,” 2009. [Online]. Available:
  • [7] Open Networking Foundation, “Software-Defined Networking: The New Norm for Networks,” 2012.
  • [8] B. Ramsdell and S. Turner, “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification,” 2010.
  • [9] T. Imamura, B. Dillaway, and E. Simon, “XML Encryption Syntax and Processing,” 2002.
  • [10] M. Bartel, J. Boyer, B. Fox, B. LaMacchia, and E. Simon, “XML-Signature Syntax and Processing,” 2001. [Online]. Available:
  • [11] S. Fowler, “HTTPsec,” 2006. [Online]. Available:
  • [12] E. Rescorla and A. Schiffman, “The Secure HyperText Transfer Protocol,” 1999.
  • [13] M. Slawik, “The Trusted Cloud Transfer Protocol,” in 2013 IEEE 5th International Conference on Cloud Computing Technology and Science (CloudCom), Institute of Electrical and Electronics Engineers, Ed., 2014, vol. 2.
  • [14] DMTF, “Cloud Infrastructure Management Interface (CIMI) Model and RESTful HTTP-based Protocol,” October 2013, DSP0263. [Online]. Available:
  • [15] OASIS, “Topology and Orchestration Specification for Cloud Applications Version 1.0,” November 2013. [Online]. Available:
  • [16] OGF, “Open Cloud Computing Interface - Core,” April 2011, GFD183. [Online]. Available:
  • [17] Docker. docker-compose.yml reference. [Online]. Available:
  • [18] CYCLONE Consortium, “Complex Application Description Specification,” CYCLONE H2020, Tech. Rep., 2015.
  • [19] W3C, “Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language: W3C Recommendation,” 2007. [Online]. Available:
  • [20] D. Martin, M. Paolucci, S. McIlraith, M. Burstein, D. McDermott, D. McGuinness, B. Parsia, T. Payne, M. Sabou, M. Solanki, N. Srinivasan, and K. Sycara, “Bringing Semantics to Web Services: The OWL-S Approach,” in Semantic Web Services and Web Process Composition, ser. Lecture Notes in Computer Science, J. Cardoso and A. Sheth, Eds.   Springer Berlin / Heidelberg, 2005, vol. 3387, pp. 26–42.
  • [21] J. Farrell and H. Lausen, “Semantic Annotations for WSDL and XML Schema,” 2007. [Online]. Available:
  • [22] D. Roman, U. Keller, H. Lausen, J. d. Bruijn, R. Lara, M. Stollberg, A. Polleres, C. Feier, C. Bussler, and D. Fensel, “Web Service Modeling Ontology,” in Applied Ontology.   IOS Press, 2005, vol. 1, pp. 77–106.
  • [23] C. Pedrinaci, J. Cardoso, and T. Leidig, “Linked USDL: A Vocabulary for Web-Scale Service Trading,” in The Semantic Web: Trends and Challenges, ser. Lecture Notes in Computer Science, V. Presutti, C. d’Amato, F. Gandon, M. d’Aquin, S. Staab, and A. Tordai, Eds.   Springer International Publishing, 2014, vol. 8465, pp. 68–82.
  • [24] M. Slawik and A. Küpper, “A Domain Specific Language and a Pertinent Business Vocabulary for Cloud Service Selection,” in Economics of Grids, Clouds, Systems, and Services, ser. Lecture Notes in Computer Science, J. Altmann, K. Vanmechelen, and O. F. Rana, Eds.   Springer International Publishing, 2014, vol. 8914, pp. 172–185.
  • [25] M. Slawik, B. I. Zilci, F. Knaack, and A. Küpper, “The Open Service Compendium: Business-pertinent Cloud Service Discovery, Assessment, and Selection,” To be presented at GECON, 2015.
  • [26] B. I. Zilci, M. Slawik, and A. Küpper, “Cloud Service Matchmaking Approaches: A Systematic Literature Survey,” in Proceedings of the 26th International Workshop on Database and Expert Systems Applications. DEXA 2015.   IEEE, 2015.
  • [27] N. Grozev and R. Buyya, “Inter-Cloud Architectures and Application Brokering: Taxonomy and Survey,” Software: Practice and Experience, vol. 44, no. 3, pp. 369–390, 2014.
Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
Add comment
Loading ...
This is a comment super asjknd jkasnjk adsnkj
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test description