Introducing TOSCA Version 1.3

OASIS has completed its public review of TOSCA Simple Profile in YAML Version 1.3, which means that this specification is close to being approved as an official OASIS standard. In anticipation of its formal publication, I’d like to offer a preview of the main new features introduced in TOSCA Version 1.3. Hopefully you’ll notice the common theme behind many of the Version 1.3 enhancements: this release is primarily focused on making it easier for orchestrators to track run-time state of deployed service components and to automatically respond to such changes. These improvements will enable you to use TOSCA not just for initial service deployment, but for ongoing service lifecycle management as well, which will tremendously increase the value of TOSCA.

Of course, v1.3 includes many other new features as well that improve the quality and usability of the specification. For a complete list, please refer to this presentation.

Service Instance Model

Before I delve into the details of the new TOSCA features, I’d like to provide additional context about the need for run-time state in TOSCA. TOSCA uses a model-driven orchestration paradigm, which means that a TOSCA orchestrator is expected to maintain a run-time model of each deployed service (the service instance model) and then use this model for on-going automated management of the service. This service instance model is created from the service template and expresses the complete structure and state of a deployed service. Run-time state of individual service components is stored in attributes of the corresponding nodes and relationships in the service topology. Template designers use the TOSCA intrinsic get_attribute function to retrieve attribute values from nodes or relationships in the instance model and then use these values as inputs to workflows, or to evaluate condition clauses in policies.

Unfortunately, while the instance model is critical to TOSCA, previous versions of the TOSCA specification offered no language support for allowing TOSCA orchestrators to keep attribute values up-to-date. This has led to incomplete, non-portable, or incorrect implementations. TOSCA Version 1.3 fixes this.

Operation Outputs and Output Mappings

TOSCA orchestrators interact with external systems by invoking interface operations on nodes and relationships as defined in service templates. Operations typically define input parameters for the specific state variables to be changed. However, many interactions also have side effects that affect the state of external systems beyond what is defined by operation inputs. For example, when an orchestrator interacts with a cloud system to orchestrate a compute node, that compute node may obtain an IP address through DHCP. While the IP address allocation is not under control of the orchestrator, the orchestrator must still be informed of the allocated address since that address will be required for future interactions with the compute node. This means that the operation for creating a compute node must include a mechanism to communicate the allocated IP address for that compute node back to the orchestrator.

TOSCA Version 1.3 supports this as follows:

• It introduces language support for defining output parameters for each interface operation that specify named and typed values that must be returned by the external system when the orchestrator invokes an interface operation.
• In addition, the output assignment syntax for these outputs consists of attribute mappings that specify the attributes on nodes or relationships into which output values must be stored when they are received by the orchestrator.

By defining output parameters and corresponding attribute mappings, orchestrators now close the loop between the orchestrator and the external systems, and they enable the instance model to accurately reflect the state of the external systems in service instance model attributes at all times.

Notifications in Interface Definitions

Of course, not all run time state attributes reflect side-effects that are the result of orchestrator-initiated operations. For example, orchestrators may simply want to monitor certain service performance or load indicators—such as system load, utilization percentages, throughput values, error rates, etc.—and track these indicators as service instance model attributes. In addition, there are situations where external systems can change independently as a result of external events such as failures or external configuration changes.

To support these scenarios, version 1.3 introduces support for notifications that represent external events that can be received by the orchestrator asynchronously. Notifications are similar to operations, except for the fact that notifications are sent by the external systems to the orchestrator rather than the other way around. Like operations, notifications can include outputs that define the information carried in those notifications. For each notification output, service templates must specify output mappings that define the attributes into which these output values are stored. This enables the instance model to accurately reflect the state of the external systems as well as any number of service indicators.

Event-Driven Life-cycle Management

So far, we have explained how operation outputs and notifications make it possible for orchestrators to accurately reflect external system state in the service instance model. This is only valuable if the orchestrator can do something useful with these attribute values. For example, can a service designer define service logic that allows an orchestrator to respond autonomously to changes in external state? Can an orchestrator take corrective action in response to a component failure? Can it scale out a service component when certain load thresholds are exceeded?

TOSCA has been designed to support this type of closed-loop automation through language support for event/condition/action policies. However, previous versions of the TOSCA language did not formally define events, let alone how orchestrators were expected to receive those events. This made it impossible to create portable implementations of TOSCA policies. The introduction of notifications in Version 1.3 of the language fixes this problem. Each policy trigger definition uses the notification name as the event that triggers the policy. As a result, notifications provide the glue that link policies to the rest of the instance model and enable true event-driven operations.

By enabling up-to-date service instance models, Version 1.3 is a significant step forward towards true model-driven service lifecycle management.