This is part three in our NetDevOps Primer series. The first post covered a brief history of network operations, and the second post gave an overview of SDN. In today’s post, we’ll gain a solid understanding of Network Automation, including some ideas for applying automation and some warnings to watch out for when you do.
Automation
Much of what people are excited by when they first hear about SDN is actually network automation. As you may already know, automation is delegation to a bot. Just as you can delegate a task to another human, like making your kid mow the lawn; you can delegate a task, project, or result to some type of machine (a bot). In other words, automation is any technology that shifts work from humans to machines. A thermostat, for example, automates the temperature control of your home – it turns the heating or cooling on and off, so that you don’t have to.
Network Automation
Network automation, more specifically, is the act of offloading network operations to software tools. Theoretically you could build a robot to pull cables for you, but in practice it’s software tools like scripts, programs, or applications that are most useful for automating your network. And almost every aspect of network operations can be automated.
Provisioning
When most folks hear the words network automation they immediately think about provisioning. Turning up new ports. Configuring a customer or department VLAN. Adding firewall rules or ACLs, etc. And you’d be right to think along these lines. Provisioning, and configuration change more generally, is ripe for automation. Especially making simple changes across large networks. Why manually log in to dozens, hundreds, or especially thousands of network devices (/functions) to make a change when you can instead write a script to do that for you?
Read-Only Automation
Automation can be about more than making configuration changes, though. In fact, it is often better to start your automation journey with read-only tasks. In traditional networks, troubleshooting often takes up as much, if not far more, time than configuration management. Anyone who’s ever had to trace down a missing VLAN or MPLS statement knows this first hand. Automation can make root cause identification much simpler, and more scalable. What if instead of training every help desk employee how to track down various network issues you could provide them with a suite of tools pre-programmed to provide the needed information to them, or to the next tier of network operations center (NOC) personnel?
Enabling & Up-leveling
Of course, providing these automation tools to more junior staff isn’t just for troubleshooting. The same technique can level up your provisioning team as well. In some organizations, the architecture or engineering team provides changes to operational staff as pre-written scripts. The best of these include all the needed pre and post checks, along with the actual changes to be executed during a maintenance window (or whenever is appropriate for that change in that org). We can also take this a step further with event-driven automation that doesn’t require any manual intervention at all; instead the network operates itself (to some degree).
The Promise of Automation
This is the promise of automation. Compounding the skills on your team to do more work with the same number of people by delegating as much as possible to the bots. An added benefit, when done right, is the reduction (and ultimate elimination) of downtime caused by human error.
The Perils of Poor Automation
These promises are not always delivered though. Complete network automation is a massive undertaking, often involving thousands or tens of thousands of individual components (interfaces, vlans, protocols, devices, etc.). Failed or broken automation can create nightmarish “fail at scale” scenarios, where a bad change is propagated across a large network in an instant, sometimes causing massive outages. And building and coordinating the needed automations is still a manual task, although one with much greater leverage than device by device operations.
This shouldn’t stop anyone from pursuing network automation. It should however remind folks to be aware of the power of automation, because, as we know: “With great power comes great responsibility.” We’ve got to plan ahead, think through, and test our automation scripts, programs, and tools thoroughly - every time.
Beyond Automation
Our introduction to “Network Automation 3.0” continues, with the next post covering Orchestration! Stay tuned. And don’t forget:
Everything in this series is available RIGHT NOW in the FullCtl whitepaper: The NetDevOps Primer.