I just returned from Cisco Live US 2017, and there was a lot happening around network automation. Everything in networking is getting an API. Tools like Ansible, Puppet, Chef, and SaltStack are being discussed as ways to automate network configuration and management. These tools were originally created to automate server and storage automation tasks. They have been adapted to network automation. Ansible seems to be gaining the most support, primarily because it is simple and easy for networking staff to use for automating tasks that were previously performed manually. The low-level structure of configuration structure is still very visible, making it conceptually easy for networking teams to make the transition from manual methods to automation.
Most automation tools use a process that runs on the target system to perform configurations, execute commands, and return status. A process on the target system isn’t a problem for servers but is a problem for networking equipment that relies on a proprietary operating system that doesn’t allow for non-native processes. The networking community has solved this problem by using a proxy process that runs on the automation server. The drawback is that the longer latency of a remote proxy slows the interaction between the device and the control system.
I think that the real problem with many network automation tools is that they are simply adding automation on top of existing command line interfaces (CLI) or XML interfaces that do little to create abstractions of the CLI. The result is increasing complexity without significant benefit.
I’ll agree that there is benefit to using these tools. Network automation forces networking teams to change their basic processes and procedures. It may not initially seem like processes and procedures need to change. Just use automation to roll out changes across multiple devices or to automate a multi-line configuration change without risk of typos (assuming that the configuration change is properly entered into the automation tool). But as the team becomes adept at using automation, they should investigate changes to their processes that streamline their operation. Look for ways to begin adopting the continuous integration practices that many IT organizations are now using.
The new processes will depend on the organization and its network structure. A public service organization such as a charity or state/local government with an outsourced and mostly static web presence will have a vastly different set of requirements than a retail company, a manufacturing company, or a hospital. Are apps hosted in-house or outsourced? Are any apps developed in-house? How are moves, adds, changes, and deletions of network connectivity handled and how can automation be used to simplify them? Tagging devices and interfaces is a good way to identify network elements by functionality in automation scripts.
I would put most of the automation tools into a bucket best described as software controlled networking. It is simply using the existing configuration mechanisms. The underlying hardware is still performing the same forwarding functions it did before and the configurations within the equipment looks the same as before. There is an advantage to using automation. It moves us away from per-box configuration, which is a big win. A useful analogy comes from the software world.
Think of the CLI as an assembly language. It has a lot of parallels:
- 1. Arcane syntax that requires significant training to become skillful in its use
- 2. Is specific to a given hardware platform
- 3. Low-level commands that operate directly on the hardware
- 4. Translated almost directly from statements into device actions
Then think of automation as an intermediate language like C, with its own similarities:
- 1. Higher-level syntax applicable across multiple machine architectures
- 2. Hardware platform independent
- 3. Low level control of the underlying hardware
- 4. Device-specific configuration statements are derived (compiled?) from the automation tool’s syntax (e.g., YAML)
Perhaps this move to basic network automation tools is the right first step, much like the progression from assembly language to the C language, and eventually to the higher-level scripting languages that are in common use today. It prepares us for the next steps in learning how to better manage our networks.
Learn how the ScienceLogic platform allows you to apply automation to improve MTTR, reduce manual effort and risk, and increase operational agility.