TOSCA Simple Profile in YAML

Oasis earlier this month released Version 1.0 of the TOSCA Simple Profile in YAML spec.  As compared to the original XML-based specification, this profile defines a less verbose and more human-readable YAML rendering of TOSCA, which will greatly simplify the authoring of TOSCA service templates. The obvious intent here is to minimize the learning curve and speed adoption for those using TOSCA to portably describe cloud applications and infrastructure.

While the simplified syntax is a nice improvement, the more important contribution of the TOSCA Simple Profile specification is the introduction of a base type system that provides high-level abstractions for most cloud service and infrastructure components. One can think of this type system as a basic toolbox—a standard library, if you will—of building blocks that can be extended and composed into more sophisticated abstractions as appropriate for domain-specific services. Again, the intent is to enable service designers to quickly compose sophisticated service templates without having to reinvent the wheel.

Note that normative types are defined not just for cloud application software (including web, application, and database tiers) but also for infrastructure components (such as compute, storage, and networking). This means that TOSCA can be used as the unified modeling language for all layers in the cloud stack, including SDN and NFV. Using a single language for all layers is especially useful in a virtualized world where boundaries between layers are often fuzzy and where layers may be recursive (for example, think Layer 2 virtual networks encapsulated in Layer 3 networks running on physical Layer 2 networks).

Last but not least, the TOSCA Simple Profile also introduces standardized lifecycle management interfaces for entities defined in TOSCA. The original XML specification required service designers to define their own lifecycle management interfaces for each component, and to provide custom workflows—plans, in TOSCA terminology—that use these interfaces to move components through the various states in their lifecycles. These workflows needed to be expressed in an external workflow definition language (such as BPEL or BPMN) which added significantly to the learning curve required to get started with TOSCA.

The specification of standard lifecycle management interfaces allows for the introduction of standard workflows in the TOSCA orchestrator, which in most cases eliminates the need for service designers to provide any workflows at all. The use of standard workflows is arguably the biggest improvement of the Simple Profile over the earlier specification. It allows for a truly declarative approach, which makes it extremely easy to get started with TOSCA.