I've had several conversations with experienced network engineers about starting to use automation instead of manual processes for doing network configuration and diagnostic tasks. For a few tens of network devices, they often consider cut-and-paste (or copy-and-paste) operations with a text editor as simpler and faster than automation.
I can't deny that creating or modifying the configurations of 10 or 20 network devices can be accomplished quickly with an editor and SSH. It might take several days for a network engineer, who wouldn't typically be an experienced software developer to create and thoroughly test an automation script. The expedient approach is frequently preferred when you're just trying to get to "DONE!"
Why Use Automation?
If cut-and-paste is faster, why are we looking at automation? Here are several reasons:
- To reduce human errors -- Studies have shown that human errors result in 60% to 80% of network failures and cut-and-paste is an error-prone, manual process. If a network device isn't reachable for a configuration change, the network engineer needs to make note to perform the configuration change when connectivity is restored. Finally, manual processes don't scale up for large networks.
- To make the network as adaptable as the IT server environment -- Many server teams have been using automation for years, creating highly dynamic server systems. Network automation can provide the desired connectivity and security in a timely manner.
- To improve configuration management -- A side effect of using manual processes is that network device configurations are applied to only those devices that need it. The result is that things like QoS configuration don't get applied consistently across the infrastructure. Automation will remove this obstacle since it will be easy to apply the same configuration across the network.
Network configurations have historically been based on sets of imperative commands -- defining how to configure the desired functionality. We need to adopt declarative configuration syntax that describes what we want, not how it works. In addition, many configuration automation systems only apply configurations as needed.
A side effect of manual processes is the one-off installation that's different from other, similar installations. Automation can help reduce the number of installation variants. The result is greater consistency across the network, with a corresponding reduction in configuration effort.
What Has to Happen
We have to get smarter. The end goal is to do more than simply convert command line interface (CLI) statements to corresponding API calls. The configuration paradigm has to change, and we need to stop thinking of configurations in terms of CLI commands and begin thinking of configurations as declarative models to implement. For example, QoS configuration becomes a set of parameters used by an automation process to configure all the devices in a managed group. The automation process is verified using a set of virtual network device instances. When the process has been validated, the configuration can be deployed into the operational network. Part of this process is identifying the key variables that need to be specified for each configuration task.
It's not rocket science. However, it's a mindset change, which can be difficult. We have a lot to learn, and our mental models have to adapt to declarative configuration models -- it's definitely a crawl, walk, run process. We'll need to use automation all the time in order to learn what doesn't work well and to think about what the next form of configuration should take.
It's going to take us network engineers a while to rewire our brains to think in terms of applying automation instead of what configuration commands to enter. We'll need to start thinking about what we want to happen, not how it gets done. When we've identified the useful automation processes and the key variables that drive them, automation will be vastly faster than our old CLI configuration methods, even for smaller sets of network devices.