Go back

The 3 Faces of Automation

December 11, 2018

People say they want automation in the same way I’d recommend improving your ‘language-ing’ if you’re traveling to a foreign country. It’s not a very precise description of what you need to do, and you might not apply the appropriate things to be successful.

Network Automation seems to be in an odd place these days. Sure, it’s desirable, and not many network engineers would go out of their way to preserve the busywork of CLI crawls, compliance audits, or other time sinks that accompany a complex network, but automation keeps getting shot down where it should be embraced.

One of the more prevalent problems in tech today is concept dilution. When companies realize there’s a craze for a new feature or ideology, there’s a rush to be in on that feature. Take cloud for example – once this methodology was sufficiently accepted by the public, an epidemic of product releases followed that supposedly had cloud implications. The same thing happened with SDN, once that became popular too. When enough people jump on a bandwagon, the original concept gets diluted and people can’t agree on what it means anymore

Similarly, many companies want to sell Network Automation, but there must be a way to precisely discuss what a tool does before it can be considered a solution to any problem. The alternative  frustrates clients with products that promise one thing and deliver another

This need for clarity is the force driving this blog post today, as I’m going to break down Network Automation into three distinct categories.

  • Network Configuration and Change Management
  • Software-Defined Networking
  • Automated Network Operations

Each of these three topics is technically Network Automation, but each one fulfills different use cases within the greater scope of the network. You might need one, you might need all three, but just as it’s essential to know what illness you have before taking an antibiotic, you should probably have the problem these tools solve before you go out and buy one.

Let’s dive in!

1. Network Configuration + Change Management (NCCM)

Change management is the ability for a network operator to remotely touch a device (or multiple devices) in order to backup or push config file changes. The content of these changes can be full configuration rewrites, such as pushing a golden configuration file onto a set of devices, or just basic things like policy removal, VLAN additions, OS updates, etc.

Companies that provide NCCM are enabling Network Operators to automate the ability to implement network changes of any complexity on a massive scale. This is a huge step up from how things used to be. Personally, back when I was a Network Engineer, I had to allow a pretty significant time frame for a large network maintenance window – every device presented an equally large set of checks and functionalities I had to manually validate.

It’s a rather simple set of features that make up the essence of NCCM, and as you’ll soon see these attributes remain mostly separate from the other expressions of Network Automation.

Major NCCM tools/vendors include:

  1. Solarwinds Network Configuration Manager (NCM)
  2. Infoblox NetMRI
  3. Microfocus HPNA
  4. Tufin Policy Orchestrator
  5. ManageEngine
  6. Cisco Prime (Cisco Devices only)

2. Software-Defined Networking (SDN)

SDN has enjoyed a very swift transformation from a curiosity to the hot and must-have data center solution. SDN is a response to the limitations of traditional networks – the ones that frequently buckle under the pressure of more users and applications consume cloud and internet to greater effect.

As automation, SDN is focused on centralized device management and programmable network provisioning.

  • Central management is achieved by abstracting a network device into a physical underlay, which manages client traffic, and a software-based overlay, which handles internal networking traffic. Through this, an engineer can control a massive amount of devices through a single user interface.
  • Then, by using a scripting language like Python, engineers can automate basic and advanced network functions, such as provisioning systems and applications, routing decisions, and even security elements of their network.

You might see the overlap with NCCM in the ability for SDN to orchestrate network functions, but the difference here is that instead of replacing individual lines in a configuration file, here a network device’s basic operations are managed by a single software application. NCCM is distinct from SDN, as in an SDN environment devices are no longer considered independent, but are part of a greater centrally managed system.

SDN provides enhanced scalability and agility to clients – respectively, the ability to expand their infrastructure without increasing CAPEX (capital expenditure – like buying new hardware) costs and their ability to increase the output of services without incurring increased OPEX (operational expenditure – like keeping the lights on) costs similarly.

Where an engineer was once purchasing and requesting new devices, they can now simply provision resources from a piece of vendor-neutral hardware and execute their virtualized network function on top of it with code.

There is certainly much more to SDN, but its essence can be distilled into these two functions (Centralized Management + Provisioning) listed above. If you’d like to know more, be sure to check out my White Paper The ABCs of SDN, which breaks down the methodology into even more granular descriptions.

Major SDN solutions include

  1. Cisco Application Centric Infrastructure (ACI)
  2. Juniper Contrail
  3. VMWare NSX
  4. Arista Software Driven Cloud Networking (SDCN)
  5. OpenDaylight / OpenFlow
  6. Huawei SDN Controllers

3. Automated Network Operations

Now, we arrive at the final category of Network Automation, which we at NetBrain refer to as Automated Network Operations. This style of automation covers a wide array of use cases, ranging from troubleshooting, network security, compliance, and even documentation. This is, in most respects, the widest and most diverse field of Network Automation, but they’re pulled together here for a specific reason – the majority of these use cases stem from the mass automation of CLI parsing and visualization in terms of data retrieval and data analysis.

NetOps Automator executing CLI commands across multiple devices

                                     an example of a NetOps Automator executing CLI commands across multiple devices.                                   

This includes troubleshooting because Automated NetOps will enable you to reduce the overhead involved in searching through devices and collecting relevant routing and interface information. Imagine trying to troubleshoot slowness between a web server and database:

  • In one scenario, you’re going through each hop of the critical path manually, performing show commands on each device and eventually figuring out that two interfaces have a duplex mismatch by the number of CRC errors accumulating during normal traffic.
  • In a scenario with Automated NetOps, your system performs those steps for you in a fraction of the time, allowing you to perform a quick device modification and restore full functionality before too many users experience issues.

The same principle of enhanced data collection can also be applied to Network Security and Compliance as well:

  • In the event of an audit, Automated NetOps would retrieve data from your devices, and analyze it against a pre-determined compliance standard (like HIPAA, FIPS-140, NIST, etc.) to determine whether it would pass.

This also includes documentation; sure, a good platform would allow you to pre-record workflows and execute them on the network, but a great NetOps Automator is going to record which actions were executed in your environment and list them for you once your workflow is complete. A great NetOps Automator would also trivialize the creation of documentation.

  • Tying back into the troubleshooting example, the NetOps Automator also provides the user with a valuable piece of documentation – a map of application dependencies. If any problems occur in the future, they will be able to reference the generated map to determine what devices need to be inspected (see below.)
NetOps Automator mapping application dependencies across a network

A NetOps Automator mapping application dependencies across a network

As you can see, these use cases are rather removed from Change Management and SDN, as they’re focused on quickly performing what an engineer would normally be responsible for.

Bonafide NetOps Automation tools are hard to come by. Orchestrating a solution with minimal human intervention requires a degree of programming, and is difficult to scale up with organizational growth and complexity.

NetBrain, however, provides the clear standout in this category: its massive library of built-in CLI parsers and network features like Comparison, Dynamic Mapping, A-B Path, Runbook Automation and more enable the user to automate the day-to-day operations that consume most of their time.

Closing Remarks

At the end of the day, Network Automation is not just a desirable goal anymore, it’s becoming a necessity for organizations to keep up with their business growth. The network is all too frequently a choke point, and as a result, people are going to seek out automation tools to fit their needs.

As this article comes to a close, let’s briefly recap:

  • If you’re not frequently making device changes, you don’t need an NCCM tool and buying one won’t serve you.
  • If you are not the manager of a data center, or if your business scales relatively well with traditional networking technology, then transitioning to an SDN environment would probably be a waste of money.
  • If you’re not managing a network for security, performance, or compliance reasons, then in all likelihood you might not need to buy an Automated NetOps tool because its value won’t offset the cost.


  • If you operate an environment that makes frequent device changes or applies golden configurations on a regular basis, then a NCCM tool is going to be essential to cutting down reaction time and freeing up your team to improve the network more effectively.
  • If your business is growing quickly and you’re getting hammered with prohibitive OPEX and CAPEX costs while upgrading, then you might consider implementing SDN into your future developments.
  • Finally, if you are a Network Engineer or MSSP that frequently troubleshoots network/security problems, then Automated NetOps would help you uphold your SLAs by cutting down the time it takes to identify the root cause of the issue.

Now, these aren’t the only use cases for the three faces of Network Automation.

Hopefully, this thought perspective has provided you with a clearer understanding of the tools you can empower yourself with.