Over the past few months I’ve been involved in various forums and discussion on what the right approach should be for achieving a common orchestration modeling language.
I felt that while there’s a growing consensus that TOSCA is currently best positioned to fit the bill, most notably in theNFV space, there are still different views on what should be the right approach to implement the standard. Some view TOSCA simply as an abstraction layer able to wrap any orchestration framework and by that provide a standard modeling on top of proprietary modeling languages.
Some view TOSCA as more than a language or abstraction layer, that represents a whole new set of philosophies on how to truly build portable orchestration.
Regardless of the approach, I think that most people would agree that the main promise of TOSCA is in its portability.
In this post, I wanted to examine more closely which of the approaches is best suited to enable true portability.
The state of TOSCA & the promise of portability
TOSCA is at the center of many of the new open NFV focused orchestration projects such as Cloudify, Tacker, Open-O, OSM just to name a few, and is quickly becoming the clear winner of common orchestration modeling languages in the Telecom NFV domain.
For those choosing TOSCA, one of the primary highlights is its promise of portability through its inherent technology agnosticism, by providing a common modeling language that can be ported across different clouds, and even orchestration frameworks. This much-coveted portability proclamation, at least theoretically, will allow users to define their application once and then run it anywhere. That said, the reality is that most of the orchestration tools that claim to support TOSCA are not really fully compatible with the specification yet.
More importantly the true value of portability isn’t just achieved by reducing lock-in, but also by enabling a greater degree of collaboration - let me explain:
Portability - The big picture
To fully understand the value of having a common standard and a portable deployment model, I would like to use what I believe to be a useful analogy from the manufacturing industry.
Computer Aided Design (CAD) provided a common modeling language to describe the manufacturing of parts. Having a common modeling language enabled much more advanced collaboration in the globalization era. It enabled different companies to define a product design in one part of the globe, and then simply and cost efficiently manufacture it on the other side of the world - exactly as originally designed. This sort of collaboration was the enabler of a revolution in design, and made it possible to manufacture much larger and complex systems such asBoeing Dreamliner 787 at scale.
“The 787 program has more than 50 Tier 1 partners located around the world, including in the United States, Australia, Canada, France, Germany, Italy, Japan, Russia and the United Kingdom. There are suppliers to the 787 program in 38 U.S. states, including significant contributions from California, Kansas, Ohio, Oklahoma, South Carolina and Washington. In all, suppliers to the 787 program are located in 19 countries and were selected based on their ability to do the work with high quality, affordability and reliability.”
The IT industry is now undergoing a similar industrial revolution to the one the manufacturing industry underwent couple of decades ago already. As with the manufacturing industry the lack of a common modeling language was a major inhibitor that limited the scale and speed at which the IT or NFV industries are able to collaborate, and consequently innovate.
When we think of portability in this context, it becomes clear that not having true portability is simply not a viable option.
Comparing portability approaches - TOSCA abstraction vs. Common Language Runtime (CLR)
There are two main approaches for handling TOSCA portability that can be classified as follows:
- TOSCA Abstraction - In this option we rely on TOSCA as a spec and let each provider implement the spec in their own way.
- Common Runtime - The other approach is having a common language runtime in which we use not just a common spec but also a common runtime that implements the TOSCA spec.
To compare which of the two approaches is best suited to deliver the portability promise I would start by looking at how other languages handles the portability challenge.
Lessons from the past on language portability - (C++ vs. Java)
Common language specification - different runtime
C++ is a good example for the first approach. We have a common spec and different providers implemented their own compiler that follows that spec. The result of that experiment is that C++ never really achieved true portability. Only when GCC became the common compiler, did we ultimately get much closer to true portability in Linux.
Common runtime and spec
Java on the other hand was born on the promise of portability - “write once run anywhere”. The reason why Java was much more successful than C++ in this regard is the use of a common runtime (JVM), which provided a common substrate for executing the Java bytecode format and the Java language. On top of this, the ability to define a clear separation between the Java language and the common runtime made the Java runtime a great platform for supporting multiple languages in addition to Java, at a later stage.
What can we learn from C++ and Java ?
TOSCA is a DSL and comes with many characteristics of a true language such as interfaces, inheritance etc. The lessons from the C++ and Java experience is therefore a useful lesson when we look for the right option for achieving true portability with TOSCA.
Based on this analogy, I would argue that if we want to achieve true portability we shouldn’t solely rely on a common spec, but rather allow each provider to implement the spec all while relying on a common runtime that implements the spec. By doing so we ensure that there's going to be one common way to interpret the spec, especially in areas where the spec is vague (and theres are still many of those areas). It is also important though to provide a useful platform to feed the spec with new features, this however should only be after they have been tested and validated. Without a common runtime it’s going to be much harder to experiment with new features before they become part of the spec.
Using a common runtime with other orchestration engines and data models
The challenge with having a common orchestration runtime is that while a common runtime may provide a common way to interpret the spec it may be limited by its ability to support other orchestration platforms. In the complex world of IT we cannot assume that there will forever be a single orchestration engine that will rule them all, and we need to have a way to integrate with other orchestration platforms. Some examples are network orchestration (ODL), data modeling languages such as (YANG) or container orchestration such as Kubernetes.
There are multiple ways in which this can ultimately be achieved.
Using TOSCA as an abstraction layer
In this way, we use can the TOSCA DSL (without the common runtime) and integrate it as an abstraction layer on top of other orchestration API.
The challenge with this approach is that by doing so we can only achieve limited portability as this leaves a high degree of freedom for interpreting the spec which ultimately results in different ways of actually applying portability in the real world. In addition, the complexity of adding TOSCA support for systems that were not designed to support TOSCA adds a fairly high barrier of complexity for integrating those systems. That is because, with this approach such platforms need to implement ALL of the TOSCA features, and not just the relevant subset that maps natively into their platforms.
Extending the common runtime through plugins
The other option would be to open the common orchestration runtime to support other orchestration platforms and data models through a set of plugins.
In this specific case plugins should provide a simple way to map other orchestration platforms as yet another TOSCA type library - a good example to that is the work we at Cloudify have done around integrating Kubernetes into TOSCA, as well as integrating other data models, for example TOSCA/YANG integration.
Mapping the current options for TOSCA Runtime
OpenStack TOSCA parser projects
- The OpenStack TOSCA Parser - This OpenStack project maps TOSCA into the Heat orchestration project. In this context, Heat serves as the execution platform. The main limitation of this approach is that Heat itself was designed to be OpenStack-specific orchestration and by tying TOSCA tightly to OpenStack through Heat, we are unable to leverage the TOSCA portability promise. We also inherit other limitations of Heat, which unlike TOSCA wasn’t designed to support the full application lifecycle management.
- Project ARIA - which was announced during Mobile World Congress 2016, is a new, open source project that aims to provide a reference implementation of TOSCA and make it easier for both network providers and carriers to embrace the standard through a simple Python library.
Final notes
The IT industry is going through an industrial revolution similar to the manufacturing industry a few decades ago. Without a portable and standard CAD model in the manufacturing industry we wouldn’t have been able to build complex systems such as the Boeing 787 in a way that is economically possible.
Having a similar standard and portable modeling language is as critical to the IT and Telco industry to enable full automation of complex systems, and to open the door for more intelligent self-managed systems, and provide better cost efficiency.
TOSCA provides a standard modeling language that is a front runner in this regard, however to realize true portability we need to learn from the lessons of other languages such as C++ and Java on what should be the best approach to enable this truly achievable. Having a common spec is often not enough as we’ve experienced with C++, and the addition of common language runtime (CLR) as in the case of Java proved to be significantly more successful model.
Standards bodies such as OASIS, ETSI, MEF as well project Open-O and open-MANO (OSM) provides a great platform for bringing vendors and customers together to agree on this, and other supporting standards to make this a true collaborative effort.
I hope that with this post will help to advance this discussion toward a final conclusion.
