enterprisenetworkingmag

Detangling the Network Orchestration Knot

By Olivier Huynh Van, CTO & Co-Founder, Glue Networks

Olivier Huynh Van, CTO & Co-Founder, Glue Networks

The performance of today’s critical apps leaves no room for error, failure or downtime. But when enterprises try to standardize deployed hardware, the situation can become untenable. With nearly 30 device types per vendor on the market, all featuring a variety of firmware, and two or three vendors in deployment, the numbers are stacking up. Given that each piece of equipment comes with a unique command line or user interface to successfully configure a device, standardization becomes a nightmare for even the savviest network engineer.

Security is no easier a riddle to solve. Cybersecurity challenges and organizational liabilities have made the security policy of a “vanilla” access list on a router a thing of the past. Simple firewalling and access control lists must be extended with more sophisticated intrusion detection and prevention systems. And using public internet transport for low-cost bandwidth requires additional layers of secured virtual networks.

“Organizations today can overcome many challenges by integrating an automated orchestration strategy that is model-driven yet enables customization as well”

In addition, many companies are now using Software as a Service (SaaS) and Infrastructure as a Service (IaaS) to address capacity planning. Network bandwidth usage and flow patterns are evolving rapidly with the introduction of additional services such as rollouts of Salesforce or Office 365. This creates unique demands on networks that were originally designed for “internal use only.” Adding new equipment to today’s complex networks can’t be done overnight.

Herding the Network Automation Cats

To offload a share of the burden, some organizations have chosen to deploy a self-service IT portal to provide help desk functionality and auto-ticketing. However, these services are typically reserved for simpler, specific tasks, such as accessing a network drive or adding access to a printer, that don’t require a change to network functions.

The point of IT helpdesk ticketing systems is to assign incoming change requests to the proper engineer, but even still, requests that are handled manually can take three to five days to implement if there is no new equipment. When new equipment like a new circuit or router is involved, turnaround time can take 30 to 60 days and may require senior architects and networking engineers to implement.

Below are recommendations for easing the transition to automation:

1. Start with small wins. The transition does not need to be complicated if the right tools and proper planning are in place. Start by automating specific pain points, such as a QoS policy first. A small success will help in the progression of applying an automation strategy when you move to the next most painful solution.

2. Create a strategy to take control. This will typically come from the executive level and relates to network features like scalability, reliability, security etc. Beginning to roll out standard policies in your enterprise, starting from simple enforcement of standards for DNS and NTP to routing and tunneling, will go a long way. These policies define the rules for each so that centralized control and policy management can be enforced. This is the start of taking control of your network.

3. Develop a model based on functionality. Node and site configuration and abstraction and modeling of standard features are vendor-agnostic and can be implemented no matter what device you are working on. Consider what you want the network to do, then build it into the rule set to develop your model. Having models for network features, node types, site type and more will help tremendously when implementing the models in an automation/orchestration platform.

4. Discover, deploy and migrate. The challenging part here is getting started early. Conducting a discovery exercise on an existing network can be complex. Understanding exactly what the current configuration state is, based on an internal configuration management database or existing documentation versus what is really there in terms of validating devices and firmware, can add to this complexity. Once the network is known, it is possible to deploy changes against your modeled functionality and migrate it to the desired state. When this is complete, it is essential to immediately protect the network against unauthorized changes, automatically monitoring the configuration state to ensure no other changes are applied.

5. Model-driven automation and orchestration. New sites are being deployed. Devices are being upgraded. User requirements and applications using the network are ever-evolving. To enable and maintain agility to service these requests, centralized model-driven automation and orchestration are necessary. This type of control of the network will ensure new devices are provisioned correctly. Policies and best practices must be maintained throughout the network. To enable this, engineering and operations must not be slowed down by automation and orchestration tools and must enable DevOps to quickly develop, test and deploy new features into the production network.

Orchestration and Customization

Because each network is unique, there is no one-size-fits-all handbook of tidy solutions. However, using the recommendations above will help you sort out what will work best in your environment. Organizations today can overcome many challenges by integrating an automated orchestration strategy that is model-driven yet enables customization as well. Recent engineering trial and error demonstrate that all networks’ nodes should be in a config-synchronized state that falls in line with the approved network model.