This article originally appeared on SDxCentral on June 12, 2018.
In the early days of cloud computing we used to spend a considerable amount of time educating customers about what cloud is, how to use it, why it’s good, and more importantly, what the cloud is not.
The one thing that always resonated with me is that the cloud is not a place, as Wired explains: “People often talk about moving to the cloud as if they were moving to another city. But the cloud is not a place. In fact, the cloud can be anywhere, in your data center or someone else’s. Organizations that believe they are moving to a strategy that leaves legacy apps and systems behind are in for a rude awakening.”
The result of this rude awakening is the acceptance that cloud, in its many shapes and forms, is about adopting a new operational, delivery, and consumption model of IT resources. Companies that were open to embracing this change with open arms were able to transform their organizations and leverage the enormous benefits that cloud models have delivered.
Today, orchestration and automation platforms are in a similar place. Many predicted that 2017 would be the year orchestration took center stage, and many were right. Similar predictions also surfaced for 2018 (simply Google: zero touch automation).
Regardless, it’s probably a good time to learn a bit about what orchestration isn’t.
Orchestration is Not Configuration Management
This has been an area of confusion for many in this space. Configuration management tools, in most cases, focus on specific technology and bring their own set of proprietary tools to “templatize” configuration elements of infrastructure, devices, applications, etc.
There are many technologies, specs, standards, and modeling languages out there that fall under the broad definition of configuration management. Some are extremely powerful, widely adopted, and are very good at what they do; the main difference between these concepts and orchestration is the ability to describe an end-to-end “service intent” that includes dozens of elements and that spans several technologies or “control domains,” which need to be operated autonomously, including full lifecycle management.
Mature orchestration platforms are designed to understand and leverage concepts like closed feedback loops that bring together metrics, analytics, policies, and actions to drive the intended service behavior. Orchestration platforms do not replace configuration management tools — on the contrary — they leverage them.
Orchestration is Not Infrastructure
Orchestration tools enable users to leverage any type of resource that is available and required by the application or service. And yes, virtualization and cloud systems do make it easier for the orchestrator to use due to the maturity of the abstraction it provides and the interfaces it exposes.
However, in the real world we still use many IT systems that are not cloud native. Orchestration platforms must be able to use any type of resource or infrastructure that is available and needed by the application, service, or organization. In other words, the orchestrator’s role is to orchestrate service intent across various heterogeneous environments. If you are dealing with a homogenous, single cloud environment you probably don’t need an orchestrator.
Orchestration is Not a Use Case or Vertical or Market
There are many misconceptions about what type of organizations or verticals are the right candidates for orchestration platforms. Some say it’s a telco thing with NFV and SDN. Others believe it’s for large enterprises that use multiple clouds and multiple data centers. Some even say that if a company is using Kubernetes, nothing else is needed. The truth is that we have seen the adoption of orchestration across the board, from small companies to large organizations, telcos and enterprises alike.
What Orchestration Is
This begs the question: If this is what orchestration is not, then what is it?
Simply put, orchestration is an operational model. At its core, orchestration is the process of designing, delivering, and operating automated end-to-end services. It’s about connecting things and processes to make the whole thing work — or, more simply put, automating the automation.
In many cases orchestration and automation do not invent anything; it takes an existing process, application, or service and makes it better, faster, and reduces errors.
Model-driven or intent-based orchestration systems take this model a step further by using a completely abstracted language that describes the service being orchestrated. This layer of abstraction is one of the most fundamental capabilities that makes orchestration truly powerful.
Focusing on what the orchestrated service is instead of how to orchestrate it is the key to delivering end-to-end service automation. It allows service designers and developers to think beyond a specific infrastructure or technology and its capabilities or limitations. And often, this process itself is the innovation and transformation enabler.
As an unknown enterprise architect once said, “I really want to automate things, but I’m too busy doing manual work.”
Adoption of an orchestration platform is not an easy task, mostly because it requires us to change and operate differently; starting with how we design services, to how we operate them, to the skills we need, to what methodologies we use.
In short, it’s a people problem.
The Orchestration Litmus Test
How can an organization successfully adopt an orchestration model? And how do we start? Here is a quick litmus test to find out if your organization is a good candidate for an orchestration platform.
If your organization:
- Operates a complex and heterogeneous IT landscape;
- Needs to evolve and transform due to market disruption;
- Is looking to avoid vendor lock-in;
- Is looking to change its operational and business model;
- Is looking to regain control of the stack;
- Needs to deliver complex services, fast;
- Has a forward thinking vision;
- And wants to own its IT destiny…
Orchestration is definitely right for you.