Maturing TOSCA

TOSCA is growing up fast. As cloud adoption is gaining steam, TOSCA is maturing in lockstep to fully support the evolving cloud landscape. This write-up provides a glimpse into how OASIS is streamlining TOSCA Version 2.0 to allow modern cloud technologies to take full advantage of TOSCA's unique capabilities:

Let’s start with a bit of history. Early adopters of TOSCA will remember that TOSCA was conceived as a technology-independent cloud orchestration language with the goal of providing the following unique benefits:

• End-to-end service descriptions: whereas other orchestration languages focus solely on deploying infrastructure or solely on deploying application software, TOSCA is unique in supporting service descriptions for the entire stack (application components as well as infrastructure), all in one place!
• Service-focused meta-model: the TOSCA meta-model is fully aligned with its mission as a service orchestration language. The meta-model introduces service topologies as first-class abstractions, where service topologies are modeled as graphs that contain the components (“nodes”) that make up a service as well as the relationships between these components. This graph-based meta model is the foundation for many of TOSCA’s powerful and unique orchestration capabilities.
• Reusable components: the TOSCA meta model also includes support for defining node and relationship types, which allows for the creation of reusable components from which complex services can be built.
• Technology-independence: TOSCA was designed to be independent of any specific orchestration platforms our cloud technologies. Since most organizations deploy services across multiple clouds, TOSCA can be used as the common orchestration language for all clouds.
• Portability: TOSCA supports the creation of portable services by using service descriptions that include abstract service components. These abstract components can be decomposed at orchestration time into technology-specific service topologies using the TOSCA substitution mappings feature.
• Explicit resource requirements: TOSCA includes concepts such as requirements and capabilities which are used to allow service designers to explicitly encode qualitative and quantitative resource requirements into their service descriptions. This further establishes TOSCA as the language of choice for expressing all service-related information in one single place.

The first versions of TOSCA were naturally focused on the prevailing cloud paradigm at the time, which was Infrastructure as a Service (IaaS), and specifically OpenStack and AWS. To support this paradigm, the TOSCA standard defines normative types for orchestrating compute, storage, and networking infrastructure as well as for deploying software components on top of this infrastructure.

Over the last several years, the cloud landscape has expanded significantly. SDN and NFV have emerged as virtualization technologies in the telecommunication space that enable a variety of networking-on-demand scenarios outside of the data center. Cloud-native software development based on a micro-services paradigm has become mainstream, and container-based software deployment has become the norm. Server-less technologies intend to further decouple software functionality from specific deployment mechanisms.

What’s exciting here is that in many ways, these new cloud technologies are actually much better targets for TOSCA’s unique capabilities than the original IaaS clouds were, for the following reasons:

• Whereas VMs are monolithic, micro services (and associated service meshes) are built using granular components with complex inter-dependencies. TOSCA service topology graphs are a natural choice for modeling micro-services.
• Furthermore, the server-less paradigm aligns perfectly with TOSCA’s mission. Consider the following definition for server-less computing as used by IBM: “Server less is event-driven programming using stand-alone functions with no deployment or operational considerations”. This paradigm fits perfectly with TOSCA’s abstract service descriptions where abstract components do not carry information about specific deployments. Implementation-specific deployment and operational considerations could be mapped to abstract service descriptions using TOSCA substitution mappings if necessary.

Because of these advantages, we’re starting to see increased use of TOSCA for cloud-native services. At the same time, this trend has made it clear that there are some areas in which the TOSCA standard might need to adapt:

• If the TOSCA standard is to be used for a variety of cloud paradigms, it must not be tied to a set of types that implement only one specific cloud.  We’re investigating decoupling the normative types from the language specification to allow the TOSCA language and the normative types to evolve and be extended independently.
• In some areas, assumptions about the underlying cloud paradigm have bled over into the TOSCA language itself. We’ll identify and remove these dependencies with the goal of making TOSCA a general-purpose cloud service lifecycle management language.
• Assumptions about the cloud paradigm may also have resulted in the language being under-specified. For example, some cloud orchestration functionality cannot currently be fully expressed using the TOSCA language based on the assumption in early versions of the specification that orchestrators must have built-in knowledge about how to interact with IaaS clouds. Additional language constructs are being added to the TOSCA language to eliminate these assumptions and to fill gaps in functionality where needed.

It's an exciting time to be part of the TOSCA ecosystem. If you’re interested in participating, please drop us a note.