Network orchestration refers to automating interactions across multiple types of devices, domains, and even potentially other related systems in the network. Orchestration typically requires the ability to interact with many device types and vendors, and across multiple domains and management systems requiring programmatic interfaces, including Restful APIs.
Network orchestration is the next stage of network automation – it can be described as policy-based or event-driven automation. While automation involves ‘making a single task run by itself without human intervention,’ orchestration goes many steps further by automating entire ‘processes,’ i.e., ‘a sequence of interrelated tasks.’ The mechanism of orchestration is defined by a set of rules or policies laid down by the organization.
Key Differences Between Network Automation and Network Orchestration
Network Automation | Network Orchestration |
---|---|
Used to run single, low-level tasks without human intervention. | Used to run multiple, sequential high-level tasks or processes, without human intervention. |
Usually done through the devices’ CLI or through third-party script-driven frameworks. | Done through programmatic REST APIs that enable automation across devices and management platforms. |
Restricted to a particular device type or vendor. | Spans multiple network services, vendors, and environments. |
Linear, does not take into account the state, status, or configuration of devices. | Network-aware, executes workflows based on state, status, and configuration of devices. |
Does not provide governance/policy management. | Has policy management and governance as a part of its principle. |
Example: Pushing configuration changes into a device. | Example: Provisioning network services. |
The tools used to orchestrate networks should encompass the tenets of orchestration – that is, they should be intelligent, work across vendors and environments, and enforce policy compliance, among other characteristics.
Device inventory: The tool must possess the ability to pull the device inventory information either directly (SSH/Telnet) and/ or through API. Inventory typically consists of vendor, model, operating system, serial number, and more information.
Context, config, and state aware: The tool should check these network parameters before it performs any orchestration activity on it. These checks ensure that the changes made to the network produce the desired outcome without causing any discrepancies. The ability to perform these checks and execute orchestration workflows based on the results is a measure of the tool’s intelligence.
Device-, vendor- and environment-agnostic: Since orchestration spans multiple services (ITSM, DDI, etc.), vendors, and environments, it’s instrumental that the tools be device and vendor-agnostic, and be able to operate across multiple environments – on-premise, hybrid, and multi-cloud.
GUI-based single pane of control: The orchestration tool should have a centralized management plane from where administrators can monitor and control operations across the aforementioned systems. For this, the tool should be capable of interacting with different tools and management platforms, for the purpose of executing commands and collecting information, through REST APIs.
Policy enforcement and governance: In automation, multiple tools can push changes into a device without proper governance, sometimes causing the device to break down. The orchestration tool should streamline and govern the execution of these automation tasks to ensure they conform to certain policies that can be enforced by the team or the organization. This way, the tool acts as the ‘master orchestrator’ for the different automation tools.
RBAC-enabled collaboration: The orchestration tool should enable application and security operations teams to self-service some of the tasks that are generally under the scope of the network team – like application traffic management and configuring firewall policies. Self-servicing of tasks, coupled with access control and governance, drastically reduces time and tickets and helps improve network agility.
Logging, backup, and restore: The tool must provide timestamped logs of every action on the network to determine what happened for purposes of audit or troubleshooting. It should also allow for on-demand/scheduled configuration backups along with rollback capabilities in case of orchestration failure.
Policy-Based Automation (PBA) – is the most basic type of orchestration. It provides an abstraction away from individual device configuration and enables centralized control to device a “policy,” which is made up of specific configuration parameters for a device type or role. Many of the technologies that use “software-defined” labeling provide policy-based automation to support implementations such as SD-WAN and SD-Access, SD-DC, and more. This approach is an improvement over the more rudimentary automation approach like network change and configuration management, but often the policies are defined in a template format, and template management can introduce new challenges. When performing updates, the PBA systems generally push the full-updated templates to the networking devices, which could be disruptive.
Software-Defined Networking (SDN) – is a higher level of network orchestration. It was originally intended to separate the control-plane and data-plane to enable higher operational efficiency in networking layer devices through programmable forwarding tables (like via the OpenFlow protocol). While this approach did not have wide adoption, other SDN technologies have had a lot of success, including SD-WAN and SDN technologies in the data center. SDN introduces a Controller layer that provides management functions such as provisioning, monitoring, and configuration management. They also provide a REST-based programmable interface for automation and interworking with other management systems.
Intent-Based Networking Systems (IBNS) – these systems are considered the most advanced from a technology standpoint since the objective can be abstracted up to a business level intent and then the system can derive the required configuration, implement on the network, and verify the network remains in that intended state. While this is one of the most advanced approaches, it can involve more time to ensure the design and required features are built properly, and the ready-to-consume intended state to be translated into actual network configurations.
Network troubleshooting is sometimes complicated and requires data gathering and analysis from many different tools. Known troubleshooting scenarios could be quickly identified and rectified with orchestration. Below is an example of BGP Flap remediation-
OS upgrade is an activity that can quickly gather complications, confusion, and delays as it rolls forward. An upgrade is a complex process involving prechecks, post checks, and approvals, which are mostly manual in today’s processes. Orchestration can simplify the method-of-procedures and remove human errors-