TOSCA in a Nutshell

The IT industry is not immune in the efforts of speeding up the production of its goods – applications and services. The best way of reducing cost and time needed to build a software solution is to cut the processes that can be done better and faster automatically without losing the essence of the process. Installing and configuring software is traditionally a manual process, and thus complex, costly and time-consuming. A much better alternative is to describe the whole application in a blueprint, then use a suitable tool to interpret the blueprint to turn it into a live application. OASIS TOSCA provides an emerging standard for describing applications in blueprints.

Virtualization technology and Cloud Computing have been major catalysts in the paradigm shift, which enabled that we are now able to treat infrastructure as if it were code. So on top of code written in Java, Python or C code, we also develop the topologies and configurations of the services required to make the application work, version them with the application’s version and store them in GIT, SVN or any other versioning system of choice. The developers can therefore indirectly take part in operations tasks, which is one of the basis of the DevOps. We should note that, here, we are not limited to virtualized solutions, but can include also the bare metal in the equation.

As a standard to describe said infrastructure and service topologies, TOSCA stands for “Topology and Orchestration Specification for Cloud Applications”. In the hands of TOSCA lies the state of the art in industrial experience and practice with deployment solutions that are both technology independent and multi-cloud compliant. These intrinsic characteristics stem from the joined interplay within which TOSCA was originally specified, i.e., the OASIS standardization effort. Within the OASIS TOSCA Technical Committee (TC) big industrial players (e.g., IBM, Huawei, Ericsson) defined the essential elements for the purpose of providing easily deployable specifications for cloud applications. TOSCA-based descriptions cover several key aspects of infrastructure, including, but not limited to, Network Function Virtualization, Infrastructure Monitoring and similar. Essentially, quoting from the TOSCA specification 1.0, “TOSCA […] uses the concept of service templates to describe cloud workloads as a topology template, […]. TOSCA further provides a type system of node types to describe the possible building blocks for constructing a service template, as well as relationship type to describe possible kinds of relations”. The diagram below outlines the essential concepts within TOSCA and their respective relation:

A typical TOSCA description is therefore phrased in terms of (reusable) node types that define the characteristics, (required/provided) properties and relations for a certain node that can be deployed as well as plans which define workflow management and execution.

The standard itself is not very useful without the tools, which take the descriptions based on standards and execute them in some target environment. Luckily, there are a number of initiatives and projects for manipulating TOSCA blueprints and orchestrating cloud applications according to the blueprints. As already explained in our earlier posts, for DICE we use Cloudify as the orchestrator solution of choice. But here are some other interesting solutions:

• CAMF focuses on three distinct management operations, particularly application description, application deployment and application monitoring. To this end, it adopts the OASIS TOSCA open specification for blueprinting and packaging Cloud Applications. Being part of the Eclipse Software Foundation, part of the CAMF code will be made freely available and open-source under Eclipse Public License v1.0.
• CELAR and the related tool-support within Eclipse, i.e., c-Eclipse.  The CELAR project is an initiative specific for multi-cloud elasticity provisioning. In realising said elasticity provisioning services, CELAR and connected tool-bases are working to implement and gradually extend a deployment engine featuring specific TOSCA templates. As part of the Eclipse ecosystem, The complete source code of c-Eclipse is made available under the terms of the Eclipse Public License v1.0. Similarly, a part of the CELAR project code responsible for automated deployment will also be made freely available as well.
• Open-TOSCA is an open-source initiative from the university of Stuttgart to develop free-libre Open-Source TOSCA modeling/reasoning and orchestration technologies including support for modelling via the Winery modelling technology as well as TOSCA containment modelling via an ad-hoc OpenTOSCA Container and instantiation via the VinoThek self-service instantiation portal. Because it is composed of a set of technologies, Open-TOSCA does not have a clear and homogeneous open-source licensing model as a single product. Rather, Individual licensing has to be evaluated for the single modules it is made of.
• Finally, Alien4Cloud is an interesting solution to manipulate TOSCA models. One of the core functionalities behind this technology is, quoting from the homesite: “Create or reuse portable TOSCA blueprints and components. Leverage your existing shell, chef or puppet scripts.” – These features suggest that Alien4Cloud may easily be integrated in the various methodological and technological phases intended in the definition and application of the DICE profile in practice. ALIEN 4 Cloud is open source under the Apache 2 License. However, Alien4Cloud was designed as a front-end for Cloudify technologies and currently it supports deployment and orchestration via Cloudify alone.

Although the maturity of these technologies is rather preliminary, they offer a basis to kick-off valuable research around TOSCA.

Damian Andrew Tamburri, Politecnico di Milano