As the acceptance of DevOps rises, the TOSCA standard has become a popular option for cloud application deployment. Here's a closer look at how it works.
No one doubts that the cloud has created a revolution in DevOps, but many cloud enthusiasts don't realize it also created a new DevOps model. That model, from the OASIS standards group, is called the Topology and Orchestration Specification for Cloud Applications.
Designed specifically for the cloud, the Topology and Orchestration Specification for Cloud Applications (TOSCA) standard is gaining acceptance and will likely influence, or displace, much of the cloud deployment and application lifecycle practices and tools enterprises currently use. Many believe that, in the long run, TOSCA will be the best and most flexible way to manage cloud deployment, and to build applications that are portable across multiple cloud providers.
As a result, it's critical for every cloud architect to understand.
How the TOSCA cloud standard reshapes DevOps
Historically, DevOps tools have been split into two groups: the declarative tools that define the expected or end state of a deployment, and the imperative tools that describe how to complete a deployment or redeployment step. The implementation of these tools has converged, but users still had to pick a primary DevOps strategy.
TOSCA changes that by supporting both models. It defines the expected state as the topology of the application, and also defines orchestration, or the sequence of steps needed to achieve that state. With a TOSCA cloud model, it's possible to be fully declarative, but also to use the declaration of an end goal as a reference to organize imperative scripts. Many DevOps teams like this approach, but it comes at a cost: TOSCA is still new, so its tools and user experience are limited compared to other DevOps options.
Cloud application deployment with TOSCA
[TOSCA] defines the expected state as the topology of the application, and also defines orchestration, or the sequence of steps needed to achieve that state.
A cloud application in TOSCA consists of a number of connected nodes called a service template. The nodes can represent horizontally distributed functions, vertical stacks of software/middleware dependencies or both. Nodes are the building blocks of a TOSCA cloud model, shaping the way an application is designed and the way in which imperative scripts are linked to applications and resources. You can visualize TOSCA templates as a series of connected stacks of nodes, each representing an application element.
Node connections are defined in relationships. Nodes have properties and interfaces, and these are referenced in relationship models that describe both the vertical and horizontal connections. Each node in a service template declares what it needs for deployment in the form of requirements, which can then be matched to the capabilities of other nodes, and in the form of configuration data, or deployment artifacts, which include the application parameters and special files.
A runtime interpreter of a service template and its associated resource topology deploys an application automatically using these requirements and capabilities, as well as the lifecycle interfaces for each node. To make this work, it's important to define the total nodal structure and connections, remembering that the connections between nodes define the deployment dependencies, such as VMs, servers and connections. In a TOSCA cloud model, it is critical to plan out the nodal structure and template it.
The role of TOSCA plans
More complex application deployment and lifecycle management is done through TOSCA plans, which also use the interfaces specified by the nodes. TOSCA plans are workflows, or sequential steps, and are often authored in a business process language, such as BPEL. Plans must be able to handle exceptions that could arise, and be able to undo what they have already done to roll back to a prior state.
Matt Rutkowski discusses key TOSCA concepts such as operational policy modeling, declarative composition and lifecycle management in this CSCC webinar.
All plans have access to the full service template, meaning they can operate across the entire cloud application deployment. They can also operate on a single application node. This allows the TOSCA cloud standard to support both local lifecycle processes, such as restarting an application in a VM or container, and global processes, such as spinning up a new set of components for load balancing.
Plans use node data to commit resources, make connections, install components and parameterize them. They also use the exposed management interfaces to control resource elements. If nodal template information and interfaces are standardized across the implementation, then TOSCA service templates are portable throughout the entire cloud environment.
The future of the TOSCA cloud standard
There are third-party applications that are TOSCA-ready, using the Cloud Service Archive (CSAR), which contains the types, nodes, service templates and plans. A variety of vendors offer TOSCA tools to build CSARs for in-house applications, or to modify those provided by others.
TOSCA is clearly different in its approach to DevOps. The differences are enough to make it complicated for those users committed to another DevOps tool, but even for users with no DevOps commitment, adopting the TOSCA cloud model can be complicated. Before jumping in, ask your application vendors and cloud providers what TOSCA CSARs they offer, and find a use case that demonstrates TOSCA deployment on a platform compatible with your own cloud target. That will give you an idea of how much effort TOSCA adoption will require.
Next Steps
Evaluate new orchestration tools for cloud
Manage cloud applications with DevOps
Evaluate cloud orchestration and integration options
Dig Deeper on Cloud infrastructure design and management
