Understanding the landscape around network automation

Automation allows for scaled activities that simply would not be possible using humans. Network engineers are at the forefront of this technology, and with it, have the opportunity to reshape their organization’s capabilities.

Take the public cloud as an example. Public cloud vendors operate massively scaled data centres (MSDCs), which can span tens of thousands of square feet and can contain thousands of servers, switches, and other networking gear. Deploying, growing, and maintaining such a huge entity, much less a fleet of them, simply would not be possible without automated processes.

Tasks such as analysing input data, processing work orders, swivel-chairing operations between systems, and communicating between groups would either quickly bog people down or require additional workers. And while adding workers is sometimes an option, as more workers become involved, the more human error impacts the workflow, and the less it scales.

In contrast, automated processes allow quick, scaled communication and coordination between systems, efficiently allocating information, updating databases, consuming resource data, and recording activity. It is automation’s predictability, consistency, and scalability that allows complicated entities such as MSDCs to exist and provide many of the services we take for granted today.

Defining automation and abstraction

There is a lot of jargon in the networking space around automation, which requires clarification. We will start first by defining and contrasting two key terms: abstraction and automation.

Automation describes an architecture that can react to events without human intervention. That is, the system can act automatically in response to an event.

It multiplies the productivity of entire organizations and is strategic in nature because it aligns with and enables common strategic objectives such as efficient growth, reducing per-unit costs, decreasing defects, and improving cash flow through reduced quote-to-cash time.

Abstraction, on the other hand, is an exercise in replacement and is helpful in simple, redundant tasks.

For example, if someone creates a python script or Ansible playbook to configure SNMP on 50 routers, they’ve abstracted the exercise of configuring 50 routers into a script that configures the routers. Instead of managing the routers directly, they manage the abstraction (the script), which in turn, manages the routers.

This is not true automation because a person has to initiate the action. That said, abstraction greatly multiplies the capabilities of a person, generally making them more productive and reducing the number of errors in their work. It also lays the groundwork for a truly automated infrastructure, a concept examined below.

There are also some key differences between where automation and abstraction act in an organization.

Abstraction exercises are the building blocks of a truly automated infrastructure because they encapsulate basic activities in the network in repeatable, scalable code. They tend to:

• Start at the grass-roots level and act from the ground up.
• Have a scope within a specific group and often begin when individuals create scripts or Ansible playbooks to perform highly repeatable, redundant tasks.
• Be huge time savers. For example, adding a new backbone router into a full RSVP LSP mesh with 100 other routers requires configuring 100 new LSPs on the new router and reaching out to 100 other routers and configuring 1 new LSP to the new router on each of the existing routers. That’s 200 new LSP configurations spread across 101 devices. Generating all those configs manually from source data and then logging in to individual devices to apply the configurations could take hours. With a python script or Ansible playbook, that could easily be condensed to a few hours of development and then execution.

Additionally, much of the development cost for abstraction is upfront: once the script or playbook is written, the next deployment is just a matter of execution.

Automation, in contrast, tends to be implemented from the top down because it is strategic in nature.

Automation projects often involve multiple groups throughout the organization working towards increasing efficiency by improving organization-wide processes, including making them quicker, less error-prone, more predictable, and less labour-intensive. For example, deploying a new rack or row of racks in an MSDC requires a high-level workflow that includes:

• Data analysis to understand when the new capacity will be needed.
• A ticketing system to track deployment activities as they progress.
• Procuring or drawing the components from inventory.
• Updating inventory.
• Transporting the components to the data centre floor in the proper sequence (racks first, then power, then switch(es), then servers, for example).
• Dispatching technicians for installation of the components at the proper time.
• Databases that hold data on the network (for example, IP addresses and ports).
• Running the fibre cables.
• Provisioning the communication infrastructure.
• Configuring the servers.
• Updating the databases with the new capacity so it can be consumed.
• Updating the ticket as items complete and closing out the ticket.

The activities above require massive amounts of data, coordination between multiple groups, and multiple systems. To the extent that these activities can be automated, they can be completed quicker, more predictably, and more consistently, which in turn, allows them to scale.

Abstraction: the basic building blocks of an automated infrastructure

When a network engineer organically builds a script to make a redundant task such as provisioning a switch to happen quicker, more consistently, and with fewer errors, they encapsulate that work and make it repeatable.

An automation platform can then use that encapsulated capability and, when it is time to provision the switch, provision it at the correct time.

The job of the automation platform is to coordinate these small tasks, executing each at the right time, to stitch them together into a coherent workflow. In other words, the automation platform’s job is to recognize specific events, and in response to a given specific event, execute the appropriate task, which in turn, creates an event for the downstream tasks to refer to.

All of this starts with a network engineer, which is why automation should not be necessarily seen as competition but another tool in your toolbox.

Tim Fiola is a twice-published author, and automation and network modelling enthusiast.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.