What is TOSCA?

We take a deep dive into what TOSCA means, how organizations are leveraging it, and why it is already the de-facto modeling language for NFV service models.

TOSCA: An Overview

The rise of cloud computing over these past few years has been immense, supported by technology developments and use by numerous sectors. Scalability and flexibility, or the pay-as-you-grow principle, provided by cloud computing have also made it very attractive and have provided a wide range of use cases for all industries. And this, in turn, has led to the development of new technologies based on cloud computing such as NFV and SDN, which are seen as the next step in network development and solutions for service providers to be more efficient and deliver new services faster.
Nevertheless, a lack of standardization in the way cloud services are operating, portability of cloud services and cloud security can potentially slow down further development. The ability to move cloud services between different cloud environments, standardize service definitions, and be vendor independent can help technologies based on cloud computing reach the next level. TOSCA helps providers do just this. It can model networks in a standardized manner, improve automation, enable portability, and more easily overcome interoperability issues.

What is TOSCA?

Topology and Orchestration Specification for Cloud Applications (TOSCA) represents a standard created by the industry group OASIS. OASIS is a nonprofit consortium that is engaged in the development of open standards supported by most vendors and major players in the cloud world as well as the telecom market. TOSCA (sometimes dubbed ‘TOSCA Cloud’) is known as one of the fastest growing standards in OASIS and has numerous use cases and implementations that have already been announced.
The idea behind the TOSCA standard is to render improvements in the deployment, termination, and any other management function of cloud applications. By defining service templates consisting of different components and the relationships between these different parts, TOSCA helps configure applications and their underlying infrastructure as well as enable moving applications in the cloud in a very unique way. Also, all required orchestration policies and resources can be defined using templates dedicated for that purpose.
The TOSCA standard has the main goal of answering the need for automation, portability, and interoperability along with the management challenges of complex cloud applications. Until now there have been two versions of TOSCA code introducing a unique language to describe its Service Template: the first is based on XML (2013), and the second one is based on YAML (2016). With the use of these two, there exist mechanisms that can then broader define services in order to describe vendor-specific or domain-specific information.

TOSCA as a Concept

The TOSCA metamodel allows for the definition and description of services by building up a topology and a way to manage it as well. The whole idea is to deploy services as a unique structure where nodes are part of the Node Template and the relationships between nodes are part of the Relationship Template. The combination of these two yields the Topology Template, which, with the addition of Plans, gives us the Service Template as the main aspect of the TOSCA model as shown in Figure 1.

Figure 1 Structural Elements of a Service Template and their Relations

Node Types form a basic part of the model and provide a description of service components that can be reused and can also be referred to multiple times when defining nodes used for one particular service. Alternatively, Node Types can be declared as abstract (cannot be instantiated in order to have common properties and behavior for reuse) or final (cannot be derived from other Node Types). The Node Template adds additional information to Node Types, such as how often components can occur or how often they can be reused in order to operate properly.
Relationship Types, same as Node Types, represent reusable entities that create a dependency between two Node Types and defines the interaction between Node Types. In the same manner, the Relationship Template refers to Relationship Types and offers additional information about relations and optionally additional constraints regarding these relations. Similar to nodes and relationships, TOSCA also uses a Policy Type and Template that define different non-functional behavior or QoS that Node Types can declare. In this way, high availability can be described.
These (Node Types and Template, Relation Types and Template) are part of a larger structure called the Topology Template, creating a collection of specific nodes and relationships in order to give all necessary information pertaining to the described service.
In order to define the Service Template as a basic structure of the TOSCA standard, we also need to explain the use of Plans. Plans are used to manage service lifecycles and provide data in order to create a running instance of the specific service. The main purpose of the Plans is to define the management part of service instances, with an accent on creation and termination. These Plans are defined as workflows, using existing language similar to BPMN or BPEL instead of providing a new language. By referring tasks to Node Templates and Relationship Templates, Plans can directly control the nodes and relationships that define a running service and also define interactions with external services. Via Service Templates, the TOSCA standard introduces reusable knowledge by defining services in detail as well as by setting rules and plans for the standard’s use. Also, in this way, the portability of cloud services should not be a problem, allowing for the possibility of any vendor being able to understand defined services in any environment that supports the TOSCA standard.

More about TOSCA

TOSCA is now the de-facto modeling language for service designs in Telcos, Service Providers, Operators and more. By adopting a model-driven standard like TOSCA, it becomes easier for these organizations to create an application-centric playground, where any application instance can be deployed faster, using the same set of configurations and with high reliability. In order for TOSCA to truly become an all-encompassing service modeling language, not just in the telecommunications vertical but beyond, in organizations like banks, financial services, and others, it will need to become a convergent TOSCA that allows building data models fulfilling the requirements of any information model (including the ETSI NFV VNF/NS information models), not just of a particularly constrained information model.
This will help realize the true potential of TOSCA and its value as a modeling language for all cloud computing applications and services.

Additional useful TOSCA resources:

Back to top