- July 21, 2015
- Posted by: Trammell
- Category: TOSCA
This article aims to introduce TOSCA (Topology and Orchestration Specification for Cloud Applications) in the simplest of terms, so that users understand what it is, why it’s important to Cloudify, and some of its basic concepts.
Orchestration magic made with TOSCA & Cloudify. Get it now. Go
What is TOSCA in a nutshell?
First, TOSCA is a specification that aims to standardize how we describe software applications and everything that is required for them to run in the “cloud”.
This means that TOSCA provides a way to describe not only an application, but also its dependencies and supporting (cloud) infrastructure.
What are the basic concepts of TOSCA?
There are two basic building blocks in TOSCA: nodes and relationships.
A node can be an infrastructure component, like a subnet, a network, a server (it can even represent a cluster of servers), or it can be a software component, like a service or a runtime environment.
Meanwhile, a relationship describes how nodes are connected to one another.
TOSCA has the notion of types.
For example, a “compute” node, which represents a resource with a CPU. These types can be used in “service templates”, or, as they are called in Cloudify, “blueprints”.
In the blueprint, a node type is used in a “node template”. So in Cloudify, a server could look like this:
This is a node template named “some_virtual_host”, and it is of the node type “cloudify.nodes.Compute”.
Both nodes and relationships may have programmable implementations, so that an orchestrator, such as Cloudify, can read their definition in the blueprint, and call certain actions.
So for example, in Cloudify, this can represented thusly:
Base types, whether they are node types or relationship types, can be derived by user to create new types. Here we demonstrate a hypothetical derivation of the Compute type into a “BladeServer” type.
How is Cloudify Related to TOSCA?
In a market of young cloud orchestration tools and products, Cloudify aims to be the best that is implementing this standard.
Cloudify’s DSL is based on TOSCA’s YAML Simple Profile, which his a way of writing TOSCA blueprints in YAML. (Originally, TOSCA is written in XML, but since XML has lots of unnecessary punctuation, the YAML profile is easier to use.)
Part of Cloudify’s core is the Cloudify DSL Parser, which aspires to read and validate TOSCA (YAML) blueprints, and provide a mechanism for mapping operations to Cloudify plugins.
All TOSCA blueprints specify the TOSCA definitions version adhered to in the blueprint. In Cloudify, we are currently using a specific Cloudify DSL version that looks for namespacing specific to Cloudify.
In the next few versions of Cloudify, the DSL will be expanded to include more features of TOSCA that have not been discussed here.
Even today, they are quite close. In this article, I’ve provided Cloudify code snippets, instead of TOSCA ones.
Could just as easily be:
A full discussion of where TOSCA and the Cloudify DSL align is beyond the scope of this article, as are the full features of Cloudify.
Instead, I’ve focused on outlining TOSCA basics. TOSCA is meant to be easy to adopt, and I hope that this article has helped in introducing the elementary concepts.
For further reading, I suggest the TOSCA Simple Profile doc.
I also recommend the documentation on Cloudify’s DSL for Cloudify version 3.2: Cloudify DSL
In my upcoming blog posts, I will begion to expand on TOSCA and Cloudify with more advanced examples.