As apps become more complex, application lifecycle management has become more dependent on tools to deploy and...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
redeploy applications and components. When the trend toward increased application complexity melds with the issues of an elastic resource pool for the cloud, it's time to assume special tools are needed. DevOps is the term commonly used to describe the cloud-driven vision of deployment and redeployment. But with the rise of the term "orchestration," it's fair to ask three questions: Is orchestration different from DevOps? What is driving the orchestration trend? And what does orchestration mean for cloud users?
DevOps emerged for app developers to communicate deployment and redeployment rules into the operations processes driving application lifecycle management (ALM). It evolved from the scripting mechanisms used for deployment and redeployment. It was also largely focused on loading components for hosting an application.
When the cloud was introduced, traditional hosting-focused scripting couldn't handle committing the resources needed to create the virtual environment for hosting. DevOps has added this step to provide for the deployment of components, the spinning up of virtual machines in the cloud and the creation of the network connections needed to integrate components and users.
Orchestration is a further evolution aimed at automating everything in a deployment or redeployment of componentized applications or services. Because both fully and automating are vague words, it's hard to assign a boundary between today's DevOps tools and evolving orchestration tools. Perhaps the best way is to look at the way standards are evolving with the example of TOSCA.
TOSCA, or Topology and Orchestration Specification for Cloud Applications, is an OASIS specification. Its purpose statement reads, "TOSCA would enable essential application and service lifecycle management support, e.g., deployment, scaling, patching, etc., in Software Defined Environments (SDE) such as Software Defined Data Centers (SDDC) and Software Defined Networks (SDN)."
It's clear that unlike DevOps tools that have evolved from hosting deployment into the present, TOSCA is designed to take future concepts back to meet and integrate with present needs and practices.
DevOps focuses on general ALM, while orchestration focuses on the cloud. As orchestration seems to be moving in the direction of a graphic or object-based approach for describing applications and deployment, DevOps is still scripting-oriented.
A future-driven view is critical for a cloud planner comparing orchestration to DevOps. The most advanced DevOps tools may look like orchestration, and some tools that call themselves orchestration are really just DevOps.
In the long run, what separates DevOps and orchestration may not be their ALM-versus-cloud starting point, but that orchestration is actually a more general and future-proof approach. That's the best approach in a market that's undergoing a revolutionary change.
Orchestration's portability a perfect fit for hybrid cloud
TOSCA and other orchestration tools allow an architect to represent the structure of an application and its relationship to resources, then allows the app to be deployed or redeployed. The structure in TOSCA is called the topology model and the description of what to do for a specific task in the ALM process is called a plan.
In theory, the same app could have a plan to match the different cloud environments for deployment, meaning TOSCA models are more portable. This approach of object-and-plan linkage is common to orchestration tools because the goal is to match applications to the cloud. Scripting is almost necessarily procedural, and it links deployment and management to fixed application-resource relationships. The model-based approach is fundamental to the cloud. OpenStack's Nova and Neutron are both examples of object-plan combinations.
The affinity between orchestration and the cloud could have major implications for cloud users and cloud builders. For private cloud users, orchestration's ability to potentially integrate cloud services and their own network or even IT services could be incredibly powerful. That same capability could be valuable in hybrid cloud applications. In fact, if we assume that hybrid clouds would make use of VPNs or private networks, a broad orchestration strategy might be essential in controlling the full range of resources needed to manage cloud bursting or failover.
OpenStack creates the proving ground for cloud orchestration
Will the cloud orchestration trend end up being absorbed into the evolution of OpenStack? That seems possible due to Red Hat announcing expanded support for OpenStack's evolution into new areas such as network functions virtualization (NFV) that require explicit orchestration. The question is whether cloud orchestration is enough orchestration.
Cloud services are really more than just platforms and software. Network services have to deliver the cloud to users. As more companies depend on the cloud for delivery of services with specific quality of experience, it will be harder to avoid building cloud services that include network features. That demands that orchestration, born in the cloud, move beyond and into managing all virtual relationships. These include virtual services to any form of elastic or flexible service resources, no matter if they're "hardware," "software" or "network."
NFV may be the proving ground for orchestration and even for the cloud. Since DevOps and orchestration are both about tools and practices to improve deployment or redeployment agility and efficiency, applications of either would be highly valuable to deploy features of telecom services. Arguably, NFV may expose the practices and tools that will not only transform telecom services, but the cloud itself.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
What to avoid with DevOps
Netflix gold standard for cloud apps
Are cloud and DevOps made for each other?