As a person who has had a front-row seat witnessing intensified efforts related to topology and orchestration specification for cloud applications (TOSCA) over the course of the past few years, I’m excited to see 2017 shaping up as the year of TOSCA.
This is based on my involvement in multiple standards organizations including the Organization for the Advancement of Structured Information Standards (OASIS), European Telecommunication Standards Institute – network functions virtualization ETSI–NFV, and Metro Ethernet Forum (MEF), as well as diverse open source communities like Open-O, OpenStack, OPNFV and agile reference implementation of automation (ARIA), in other venues featuring information/data modeling activities such as Layer 123 NFV/ software-defined networking (SDN) World Congress, Multi-Standards Development Organization (SDO) Information Modeling workshops and most importantly, in direct product engagements and deployments with customers (operators, enterprise) and virtualized network function (VNF) vendors.
In my searches for more data on TOSCA, I was looking for something to break it down for me simply and give me an overview of history, developments, and what’s coming – and since I didn’t manage to find any kind of document of the sort, I decided to write it myself to help others who may feel the same way.
This is important because while all this attention to TOSCA is good news, many questions and challenges remain to be addressed if we’d like this to pan out to be the good year of TOSCA.
So I’m going to take a moment to backtrack a little to cover background and landscape for those only getting their feet wet with TOSCA. This is because I’m looking to make TOSCA knowledge more accessible to those who may be interested but cannot afford to follow and/or influence the ongoing activities, in addition to those who are already involved.
[NOTE: Unless otherwise specified, I will use “TOSCA” to mean “the TOSCA ecosystem, framework of artifacts, philosophy” in a broad sense, encompassing everything related to TOSCA. I will do my best to be more specific when referring to a particular specification, implementation, or some other artifact.]
TOSCA stands for “Topology and Orchestration Specification for Cloud Applications”. Version 1.0 of this specification relied on extensible markup language (XML) Schema 1.0, and was published by OASIS in November 2013, and starts by stating its intent:
“Cloud computing can become more valuable if the semi-automatic creation and management of application layer services can be ported across alternative cloud implementation environments so that the services remain interoperable. This core TOSCA specification provides a language to describe service components and their relationships using a service topology, and it provides for describing the management procedures that create or modify services using orchestration processes. The combination of topology and orchestration in a Service Template describes what is needed to be preserved across deployments in different environments to enable interoperable deployment of cloud services and their management throughout the complete lifecycle (e.g. scaling, patching, monitoring, etc.) when the applications are ported over alternative cloud environments.”
Since then, OASIS switched gears to develop the TOSCA Simple Profile in YAML Ain’t Markup Language (YAML) Version 1.0, published in December 2016, which starts with:
“The TOSCA Simple Profile in YAML specifies a rendering of TOSCA which aims to provide a more accessible syntax as well as a more concise and incremental expressiveness of the TOSCA domain specific language (DSL) in order to minimize the learning curve and speed the adoption of the use of TOSCA to portably describe cloud applications.”
The work on “Simple YAML” continues and we expect a new version to be published this year and is not stopping there.
A lot of additional TOSCA related projects were, and still are happening in parallel inside and outside OASIS (not all of them directly visible to OASIS) – and most of those are at the same time NFV-related. In the figure below I paint a non-exhaustive landscape/timeline of projects in different organizations that either impact TOSCA or are impacted by TOSCA – and the relatively complex (in some cases, circular) dependencies between them.
Figure 1: TOSCA landscape and timeline — Photo Source: Gigaspaces
One can indeed see by the agglomeration of, and industry interest in TOSCA-related activities, why my instinct says that 2017 is shaping up to finally be the year of TOSCA. This becomes even more apparent when compared to any other potential candidate specification/framework pitched for deployment, orchestration, or automation of cloud and NFV workloads. This is a great sign that TOSCA is emerging as the consensus primary vehicle in this space, which is an important milestone in standardizing and defragmenting this industry.
Although, that said, we do need to strive to ensure that these multiple dependencies and [too] many open questions about evolution will receive the significant industry efforts required in the standards bodies (ETSI NFV, OASIS/TOSCA) to reach optimal, or at least satisfactory, resolutions. While an initial satisfactory specification, “TOSCA for NFV” is within reach in 2017, I believe that the “optimal TOSCA” may undergo resets and iterations because of the multiple parallel tracks that will continue their activities at least into 2018.
One thing important to note is that the accelerated emergence of potential TOSCA extensions implemented in open source projects today is a good sign that those communities are willing to adopt standards. This essentially means that the standards community will have to reciprocate by taking into consideration this important and integral feedback from live implementations – a de-facto healthy co-opetition that will ultimately serve to accelerate industry adoption.
A word of suggestion to the operators, service providers, and telcos that are “almost” sold on TOSCA may have to make hard interim decisions, while waiting for the optimal outcome. This is also true for vendors that are committed to TOSCA. Ultimately a product that works well and is close enough to compliance is preferable to a product that is compliant, but only close to working well.
Albeit, given the landscape painted above, it looks like the community will continue to ask during 2017, “compliant to which TOSCA specification?”
I will be following up in upcoming posts with specific developments, issues, challenges, and successes in different TOSCA-related projects mentioned in the landscape.