An initiation into infrastructure automation tools and methods
A comprehensive collection of articles, videos and more, hand-picked by our editors
Application provisioning has been done for years, but with the advent of cloud, it's become a specific step in...
application lifecycle management. The increased importance of provisioning sparked tighter integration between developers and operations -- a trend known as DevOps.
Now, cloud planners and architects are hearing about cloud orchestration -- but what is it and how does it differ from provisioning? Here's one way to think about it: The difference between provisioning and orchestration is like the difference between walking and dancing.
What's cloud all about?
Early cloud deployment differed from data center deployment by addressing a pool of resources rather than specific system targets for component placement. But, as cloud knowledge advances, users view it as more than that. The cloud is about agility and scalability in response to failures and load changes. It's about matching hosting locations with geographic distribution of users, and integrating cloud and non-cloud elements. But, most of all, cloud is about management.
Provisioning assigns resources to applications and components. It consists of three primary tasks: identifying available resources, deploying those resources and integrating deployed components. To ensure consistent provisioning, most operations teams rely on scripting tools. And every major server operating system has both built-in and add-on tools. Enhancements allow these tools to handle resource variability found in virtualization and the cloud -- which is how DevOps tools emerged.
Provisioning is about how to get there; it's a set of instructions and considered an "imperative" approach. To make known but un-deployed resources available, provisioning presumes a fixed progression. Provisioning scripts might say "deploy this" and "connect that," but it's a fixed process.
So what if there are multiple paths to make a resource available? And what if there are different states of availability? That's where orchestration comes in.
Cloud orchestration is about goals and states -- not steps. It's based on a declarative model, which defines an end goal or state, but not the path to get there. Orchestration software determines that path, which is based on the goal and current state. That means orchestration defines all possible twists and turns associated with deployment, and considers them while determining how to achieve the final goal.
This is something new that orchestration delivers: a lifecycle. Provisioning gets you running, while orchestration identifies end goal departures and keeps things on track. As applications become more complex and as cloud integration and cloud bursting become more common, application failure or poor performance could increase. As a result, orchestration becomes more valuable.
If lifecycles and current states are critical to orchestration, then management integration is an orchestration tool's most important component. For an orchestration system to pursue its goal, it must know the state of the resources tied to the specific application being orchestrated. That requires status feedback on everything that's been deployed and uncommitted resources.
A closer look at cloud orchestration tools
It's early in the evolution, but vendors and users increasingly turn to big data and analytics to determine an application's state as it's deployed and run. Collecting management data and analyzing it in real time allows an application to recognize changes in its operating state. This information can be used to set an application's "current state" and define the orchestration process.
To enhance deployment steps, orchestration automatically accommodates a wider range of conditions. However, this requires defining application and resource states, as well as the accommodation of various conditions or events in each. This progression from state to state, driven by events, brings an orchestrated application to its goal.
Some advanced cloud tools, such as those based on OASIS' Topology and Orchestration Specification for Cloud Applications (TOSCA) from vendors like IBM and Cloudify, are built to address orchestration. Some DevOps tools, like Puppet, are also evolving towards orchestration and its declarative model. Additionally, the European Telecommunications Standards Institute's (ETSI) Network Functions Virtualization (NFV) Industry Specification Group is formalizing an orchestration-based service deployment architecture that could be adapted for cloud applications. In other words, we are starting to see a broader acceptance of orchestration.
And that's a good thing. The cloud and its applications aren't getting any simpler. The trend toward application personalization and customization creates more complex workflows and application structures. Meanwhile, these personalized applications require details such as a worker's location -- and this social context adds another dimension. Combine this with public or private cloud, along with component migration in the cloud, and it becomes too complicated to describe as a script.
Transitioning to orchestration won't be easy. Operations teams prefer imperative tools because they think of provisioning as a linear process. While many recognize a need for change, orchestration models aren't any easier to learn. But, no matter how complex a transition, the cloud's own evolution is driving towards orchestration. And the sooner the operations and cloud planners accept this, the sooner they'll be able to prepare.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
Following DevOps evolution
How to separate DevOps and orchestration
Managing cloud apps with a CAMP-centric approach