The case for declarative network automation

Nemertes recently looked at how organizations with larger networks—specifically Cisco-heavy networks—implemented network automation. The results were a bit surprising in that less than 20% use Cisco’s flagship DNA Center network controller and management dashboard that can automate provisioning and change management.

On the other hand more than 40% roll their own automation solution using various forms of imperative scripting or programming (mostly Python), and about 50% engage a different model instead of or in addition: declarative automation.

Imperative programming

The idea of imperative programming is writing programs that are a series of instructions such as “Do A then do B then if X happens do C otherwise do E.” The majority of the most-used programming languages are imperative (C++, C#, PHP, and Python). The current trend for more network automation is pushing many network professionals to dust off old programming skills or pick them up for the first time.

The effort is non-trivial for network staff unused to this style of programming or who simply find it difficult and joyless. Those detailed instructions can be very involved and can consist of many steps for even a single configuration change. Those steps can be sequence-sensitive (thing 1 has to be done before thing 2 is done or thing 1 undoes the effects of thing 2), and timing-sensitive as well (thing 2 can’t be done until some minimum amount of time after thing 1 happened or must be done before some maximum time afterward). Also, the engineer-as-programmer has to be as careful to do only what is needed as to do everything that is needed.

Declarative programming

Some network staff find declarative approaches more congenial. Declarative programming focuses on defining the desired result of the program rather than the steps to take to achieve it. HTML can be considered a declarative language—“This web page should have this text in this size, and that image underneath, and two buttons here and here to take users to pages B and C.” So can SQL—“The data set should contain all the records that meet conditions A and B and C.”

Declarative approaches to network automation take a lot of the burden of programming off network engineers. People can focus on how a device or service should be configured rather than figuring out the detailed instructions for achieving that configuration correctly.  That is, they can focus on statements like “Ports 1 through 24 should be configured to 1Gbps full duplex. Ports 1 through 12 are on VLAN A. Ports 13 through 24 are on VLAN B.”

Nemertes’ Network Automation Research Study 2022 found 33% of the organizations interviewed used Ansible for network automation, and 17% used Gluware. Ansible has come to prominence mainly as a result of the growth of DevOps and of the infrastructure-as-code paradigm associated with DevOps. It used a purely imperative model in its first versions, but about five years ago added support for declarative models as well. Network teams have been adopting it as a means of automating network management across both data center and branch/campus networks. Gluware has evolved specifically as a network-automation tool and primarily for Cisco-centric networks.

Declarative lightens the load on network engineers

The shift to declarative models for network automation eases the burden on network teams, especially in the face of steadily evolving network OSes. An engineer who doesn’t have to worry about whether an OS update means the commands needed to achieve a specific state have changed is an engineer who can focus more attention on making sure the desired state is still correct and achievable. It can also ease the burden of working across different network vendors’ platforms. Again, the focus can be on defining the state correctly and not on the fiddly differences between command languages on Arista vs Cisco vs Juniper.

The flip side of that, though, is that the organization has to rely entirely on the platform being able to correctly configure the gear in their network. This is usually a safe assumption for the biggest vendors and their relatively new gear, but not as safe to assume for smaller vendors or older gear or older versions of operating systems on older gear. It is worth noting that in the Nemertes study, which was focused on getting information about Cisco network management, only 25% of the organizations had an all-Cisco routing and switching estate. Most organizations had two or three vendors involved.

So with the usual tradeoff on trusting tools provided by vendors to handle imperative automation behind the scenes, declarative automation offers a powerful tool with which network teams can advance the cause of broader automation without having to devote themselves to becoming imperative-style procedural programmers.