The TOSCA Times (Part 1): The TOSCA Landscape in 2017
The TOSCA Times (Part 1): The TOSCA Landscape in 2017
Is 2017 the year of TOSCA? It could be! Let's take a look at what TOSCA is, how it works, and what's in store for the future of cloud applications.
Join the DZone community and get the full member experience.Join For Free
Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
As a person who has had a front-row seat witnessing intensified efforts related to 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 (OASIS, ETSI NFV, MEF), in diverse open source communities (Open-O, OpenStack, OPNFV, ARIA), in other venues featuring information/data modeling activities (Layer 123 NFV/SDN World Congress, Multi-SDO Information Modelling workshops, …) and most importantly, in direct product engagements and deployments with customers (Operators, Enterprise) and 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, or an implementation, or some other artifact.
TOSCA stands for “Topology and Orchestration Specification for Cloud Applications”. Version 1.0 of this specification relied on 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 Version 1.0, published in December 2016, that 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 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 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
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, e.g. “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 competition 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.
You are welcome to reach out and comment if you have any questions or would like to have upcoming posts focus on a specific subject, so we can build a conversation around TOSCA.
Published at DZone with permission of Michael Brenner . See the original article here.
Opinions expressed by DZone contributors are their own.