What networking automation tools should you consider?
When launching network automation projects, do you craft custom scripts or buy off-the-shelf networking automation tools? It probably depends on your team's capabilities.
Networking automation is a popular topic, but IT pros are puzzled by its many meanings. It can mean automating command-line interfaces, or CLIs, with canned scripts by using programming languages, like Python, to access the APIs of network operating systems. Or, alternatively, automation could entail using software-defined networks that are managed through a controller.
Do these examples constitute networking automation, and why does it matter? Much of IT infrastructure -- including cloud and traditional on-premises systems -- has become dynamic. But networks have not kept pace, and, therefore, we don't want them to become bottlenecks.
Enterprises view with envy how large cloud operators customize software-defined networking (SDN) to automate their vast networks, but that's not practical for enterprises. To attain agility, organizations could implement off-the-shelf components within their SDN systems, but that might not be practical for enterprises with existing hardware.
Are there easier ways to start? Writing CLI-based scripts is a familiar, yet error-prone, method that won't scale well. Writing programs in languages such as Python or Ansible to use the APIs in modern network devices is a good step toward treating infrastructure like code. It can be compatible with existing equipment and provides agility via automation.
Is this a sweet spot for networking automation -- neither too simple nor too technically ambitious?
Find compromise in networking automation tools
As a starting point toward networking automation, organizations could download automated scripts from template repositories. You could customize a few parts to get off the ground. This path is tempting to get early success without much effort.
Coding can be fun, too. It's a good career skill to add, and the results can attract praise. But it's a slippery slope if it consumes the efforts of your networking team as debugging tasks pile up. You don't want coding to impede your network management.
You need to assess your capabilities. Organizations need to be aware that networking pros may not become expert programmers.
This is when you need to assess your capabilities. Organizations need to be aware that networking pros may not become expert programmers. Training, debugging and maintenance tasks may be underestimated and may be difficult for multivendor environments.
This strategy is perhaps best suited for a knowledgeable or large team that can afford to invest enough resources for this task. Even if it works for the team, always realize there is an opportunity cost of doing something else.
Alternatively, vendors or open source projects may provide tools that use the devices' APIs, but packaged as a canned service, which relieves the networking pros from developing custom scripts. This is not a full vendor-provided SDN system, but a service that is equivalent to scripted automation that is bought off the shelf.
This is a reasonable compromise in a build vs. buy quandary, and I recommend it for organizations that have a lack of automation, but can't afford to invest resources to develop custom scripts.
Most modern network operating systems, such as Cisco's NX-OS or Juniper's Junos OS, have APIs to support scripting for networking automation. The vendors' products, such as Cisco DNA Center or Juniper Contrail, provide out-of-the-box networking automation services. Disaggregated networking OSes, such as Cumulus Linux, and third-party automation tools, like Apstra AOS, offer various forms of vendor-independent networking automation, as well.
Networking automation recommendations
First, assess your needs and business goals. Organizations with complex needs may develop in-house programming skills for networking automation that does not fit into a packaged service. But do so only if you can develop those skills and hire experts.
For others, off-the-shelf networking automation tools are appropriate, as long as you understand the limitations in flexibility. A hybrid service is possible, but organizations need to understand the boundaries of an out-of-the-box service and when a custom script makes sense.
