Realizing the Full Power of TOSCA through Abstraction

Most real-world TOSCA use cases today don’t utilize the full power of the technology. While TOSCA was designed as a service modeling language for cloud applications, its use to date has been mostly limited to orchestration of cloud resources on IaaS or PaaS clouds (and then installing software applications on top of those resources). I’m not arguing that this isn’t a valuable use case. Cloud deployments are complex to manage, and TOSCA’s declarative approach is an important step towards cloud simplification. Using TOSCA, service designers can avoid having to imperatively invoke cloud APIs directly and instead focus on what resources need to be instantiated rather than on how to do so. In the resource orchestration use case, TOSCA provides a fully declarative, standards-based, and portable alternative to technology-specific template languages such as Heat Orchestration Templates (HOT) or Amazon Cloud Formation Templates.

That said, this use case doesn’t come close to taking advantage of the full power of TOSCA. In the resource orchestration use case, TOSCA is effectively reduced to the role of deployment descriptor—a glorified install script if you will—that describes the exact topology of the resources that need to be instantiated and configured, and how these resources need to be interconnected. This requires the service designer to manually work out the low level details of their service topologies down to the individual resources required and their associated configurations. The result is often a bottom-up approach to service design where service designers run the risk of losing track of (and being unable to deliver) the high-level business objectives that their services were intended to provide in the first place.

A better alternative is a top-down approach to service design that starts with a high-level description of service functionality and associated business goals, and then drills down into increasing levels of detail where at each level the goals and objectives from higher levels are translated into concepts that are relevant to the lower levels.

This top-down service design process can be accommodated by allowing services to be modeled at different levels of abstraction. At each level of abstraction, a service is modeled using only those concepts that are required for that level while eliminating any unnecessary details that are not relevant for that level.  An abstract service model can be deployed only by translating it into a service model at a lower level of abstraction (thereby adding the necessary details required by the lower level), and applying this translation process recursively until the service model is expressed in terms of actual resources that need to be committed.

Note that the concept of recursively translating different levels of abstraction is not new. John Strassner introduced it in the context of his work on policy-based networking and directory-enabled networking. His DEN-ng framework introduced the notion of a policy continuum that proposed at least the following five different levels of abstraction depending on the point-of-view of the person managing the service:

• Business view: describes service functionality to be provided and the associated service level objectives (performance, uptime, security, etc.).
• System view: provides architectural components that make up the service functionality using descriptions that are largely technology-independent.
• Administrator view: drills down into specific technologies for each of the functional components in the system architecture (but doesn’t worry about specific devices or vendors)
• Device view: describes specific devices (including vendor-specific models)
• Instance view: describes deployment information tied to the different instances of the various devices and the specific resources used by those instances.

While these levels of abstractions were introduced in the context of network services, they apply equally well to the broader class of cloud application services. This is where the real power of TOSCA comes into play, since TOSCA fully supports this recursive mapping of levels of abstraction:

• TOSCA allows service designers to model their services at various levels of abstraction. Each level of abstraction is modeled using abstract nodes that model only those capabilities, requirements, and properties that are relevant to the specific level of abstraction. 
• TOSCA supports translation between different levels of abstraction through the concept of substitution mapping. Using substitution mapping, any abstract node in a service topology can be replaced with an entire sub-topology (described in a different service template) that provides the additional detail (functional as well as structural) required for the lower level of abstraction. The substitution mapping process maps the capabilities, requirements, and properties of the higher-level node onto equivalent capabilities, requirements, and properties of nodes in the sub-topology that represents the lower level of abstraction.
• Substitution mapping can be applied recursively until all abstract nodes have been eliminated and the service topology consists entirely of concrete nodes that can be deployed onto available infrastructure resources.

By supporting a top-down service design approach that starts at the highest level of abstraction, TOSCA can dramatically simplify the service design challenge. In addition, I envision that future TOSCA orchestrators will include a growing catalog of modular service templates for commonly-used abstract nodes. The templates in this catalog will act as a library of available building blocks that allow the substitution mapping process to be largely automated over time.