Automation First

Network automation. Ten years ago, that term was used to describe an aspiration or a group of scripts or Ansible playbooks used to perform limited task-based operations on the network. Today, the term network automation means something much different: network automation describes a methodology for running a network by orchestrating tasks into workflows that deliver value to the firm and its customers. Network automation is no longer a side project: it is becoming a requirement for firms to stay competitive and gain competitive advantage. With that reality, networks must be designed and even re-architected to support automation. Automation first. This post will explore what that means.

Every Decision Should Filter Through the Lens of Automation

To optimize the advantages of automation to the firm, each and every decision must take automation into consideration. Below, we discuss some examples of what that really means in practice.

The Network Architect

In legacy network architecture, the Network Architect is asked to design a network around specific business requirements such as:

• Minimizing capital expenditures (CAPEX)
• Specific network performance requirements
• Failover requirements to meet service level agreements (SLAs)

To this list of business requirements, the architect must add automation: business processes may need to be changed from the current status quo in order to facilitate the network automation flow. If automation is not on the list of business requirements for the network, the architect must explicitly ask for guidance from the business because the business itself may not fully understand that network automation adds additional criteria to the network architecture.

Network Architecture

Here are a couple of likely scenarios a network architect may need to work through when considering automation first:

• Automating on chassis-based switches is more complex than fixed (single forwarding engine) devices
  • This fact greatly affects how many chassis are deployed, where they are deployed, and their physical topology
• There may be instances where a 5-stage CLOS data center architecture lends itself better to automation than a 3-stage CLOS
  • In this situation, Architecture must consider a higher initial CAPEX spend for the 5-stage CLOS in return for lower operational expenditure (OPEX) over time
• How will the business interface with the automation infrastructure?
  • The architect must consider how the existing process for requesting a network feature or service functions and whether this process will continue to function with automation in the mix
  • The ideal state for this interaction should minimize the amount of human involvement much as possible

Hardware Vendor/Device Selection

When considering network equipment vendors and specific vendor models, the architect should add “Automation Friendly” (i.e., a robust API set or other management access beyond CLI/SSH) to the list of hardware requirements.

If the architect wishes to simplify automation infrastructure, they may want to consider whether the vendor offers a quality software controller for its devices. To put this another way, the firm must decide whether a given vendor will be a good partner in the automation project. Leveraging a vendor’s domain-specific controller can greatly simplify the organization’s own automation infrastructure because the firm’s infrastructure only has to interact with a single controller or group of controllers, versus hundreds or thousands of individual devices from that vendor. Keeping that in mind, if the organization does leverage vendor-specific software, it is essentially becoming partially dependent on the device vendor, and it may be more difficult in the future to change vendors or shift to a multi-vendor strategy.

Management and Workflows

Another important set of items for an organization to consider in an automation first outlook is their processes and workflows. A business creates workflows to coordinate actions between different groups in order to deliver value and generate revenue. The organization must be willing to examine its workflows to understand how the workflows may need to change in order to realize benefit from any automation efforts.

Automation first requires senior management to encourage cooperation between groups, including changing the metrics for the various groups. If the metrics to measure progress in automation are not put in place, the various groups will have a more difficult time coordinating. Additionally, creating automated workflows may involve reorganizing various groups’ interactions within the organization to better fit into automated workflows.

People

Finally, it is people that make automation possible. In many instances, Network Engineers (NEs) will transition into Network Automation Engineers (NAEs). This means that many of their daily tasks will change. This requires NAEs to think differently than they did as an NE.

One example is how change is driven into the network. An NAE drives change via code, whereas an NE drives change via CLI. As such, the NAE will spend time on tasks such as designing and maintaining configuration templates or writing automation scripts that express network configuration intent versus manually configuring devices.

NAEs must also avoid the trap of saying “I’m only going to do this once, so I won’t automate it.” In reality, most anything you have to do once, you’ll have to do again. Think about iteration: if you perform a task manually, and then you have to go back and fix mistakes, this means you’ll have to do the entire task manually again (and perhaps again, if there are other mistakes or changes are needed). Additionally, there may be sub-tasks of that task that would be immediately reusable. Automation first means accepting that tasks are typically repeated, and that your code should be logically split up into component parts that can be used in other tasks or processes.