I had a great chat about the benefits of network automation with Christoph Jaggi a while ago, resulting in 2-part interview published by Inside-IT. As you might prefer to read the English original instead of using Google Translate, here it is (or you could practice your language skills and read the German version).

What are the primary use cases for network automation?

Every process that can be unambiguously described in enough details can be automated. Obviously you’d want to start with something simple, for example collecting data from network devices and generating reports that are not provided by the network management tools.

Next step might be automated troubleshooting. Most troubleshooting processes involve heavy data collection that can be easily automated. You could even automate simple procedures (example: check whether there are any errors on the port to which the user is connected).

Changing device configuration is already a bit riskier. Most environments start this phase of network automation with automated deployments of new devices or new sites (where the risk of breaking things is relatively small). The obvious next step is automating site refreshes.

After you’ve mastered automated device deployment it’s time for automated services deployment – changing device configurations through a self-service portal or an orchestration system.

The final stage of network automation is event-driven automation (what some vendors call self-driving networks): responding to changes or external events, and adjusting the network configuration in real time.

Note to ipSpace.net subscribers: I covered simple report generation and device configuration management in Ansible for Networking Engineers, and talked about several real-life uses of network automation in Network Automation Use Cases. All use cases mentioned above are described in the Building Network Automation Solutions online course.

What is the difference to datacenter automation?

There are two fundamental differences between typical network automation and automation of most other parts of data center infrastructure:

• Network automation usually works with physical devices (switches, firewalls, load balancers), whereas you’d commonly use server automation on virtual devices that can be easily destroyed and recreated if something goes wrong. It’s also worth mentioning that nobody in their right mind goes very far in automating traditional storage.
• Impact of mishaps (blast radius) is much higher in network automation. Crashing a server brings down a single application, crashing a database server (assuming you never invested in proper redundancy) brings down multiple applications, crashing a core switch could bring down whole data center.

To make matters worse, most network devices aren’t as easy to automate as servers. You can’t run scripting languages (bash, python…) on many network devices, and even when you could, they still interact with the device operating system through the CLI that was designed for a human operator. Unfortunately most network automation still looks like screen scraping we used when we tried to integrate IBM mainframes with the web.

Note to ipSpace.net subscribers: some challenges we’re facing when interacting with network devices are described in Network Automation 101 webinar. For more details watch Ansible Networking Modules part of Ansible for Networking Engineers (also included in Building Network Automation Solutions online course).

What are the key benefits?

Speed and increased efficiency are oft mentioned as the obvious benefits. However, one should not forget consistency and resulting increase in reliability. It’s really hard and error-prone to create a complex service that involves changing a dozen device configurations by hand using a lengthy manual process – the same process becomes significantly more reliable when it’s automated (or at least the automated process is making consistent mistakes every time it’s run).

It’s also easier to enforce consistent security rules when the device or service deployment is automated… and when you block network operators from making manual changes to network devices the dreaded audits should become way less cumbersome.

Finally, an automated service deployment process alleviates the need for strict maintenance windows, as device configuration changes no longer represent a change that must be documented, reviewed and planned. The only real changes that have to be managed with frameworks like ITIL are deployments of new versions of the automation system.

More in part 2…