A great new book on Network Automation with Go just dropped recently and if you want to get into automation parts of your network or wants to start doing so with Go, it’s definitely for you!
It contains a lot of background on the Golang programming language, its concepts and how to use them to build reliable, scalable, testable, and observable applications. The authors also discuss Network Automation and configuration management approaches in general, and dig into APIs and network monitoring.
The book closes with a special chapter called Expert Insights, where the authors asked several people, who have real-world hands-on experience with Network Automation with Go to provide their thoughts around this topic. I think it’s a great idea to catch a lot of different views and ideas and share them with the readers and I’m especially honored that I’m one of those people, who had the opportunity to share some ideas and thoughts around Network and Infrastructure Automation (with Go), which I also want to share here.
So without further ado, here the insights I shared in the book:
A little bit of history
Coming from a Linux Administrator / Systems Engineering background I’ve been used to having home-grown automation solutions in place to manage a fleet of — for me at the time — large number of servers and clients since my first job at the IT center of the Institute of Mathematics at Paderborn University in early 2004.
We had a locally developed software suite called SDeployment — written in Shell if I remember correctly — which was responsible for provisioning the correct software packages and desired configuration file state onto Linux based servers and clients and enforcing the desired state to stay this way.
This even helped to detect an intruder who managed to exchange the sshd binary, which didn’t have support for Kerberos, so he needed to change the sshd_config which got overwritten after one hour and the service didn’t start anymore.
At the time this was a huge benefit over solutions like cfengine, which could do incremental changes to configuration files but not maintain them holistically; Puppet had not been born yet (according to Wikipedia).
With the rise of bcfg2, Puppet, Chef, Salt and Ansible we saw a shift from incremental configuration changes to intent based configuration management in the wider industry, where the operator describes the desired state (intend) and writes templates to generate the contents of entire configuration files, and the configuration management solution’s task is to make this a reality and keep it this way.
Mental shift to holistic automation
The Systems Engineering / SRE world has undergone this shift of thinking a long time ago, but it feels like the majority of network automation solutions are still following the idea of making incremental changes to the routers and switches out there, which at the same time might also be managed manually by operators typing (or copying) magic spells into a CLI.
This makes the device configuration the synchronization point and we don’t really have an idea of what this configuration will look like in full without checking back on the device.
I believe we as Network (Automation) Engineers need to follow suit, make the mental shift to the holistic approach, let Perl, Shell and expect scripts be, and bring software engineering methods to network automation. This way we are able to tackle the problems at hand at an abstract level, build solutions which can be reasoned with, tested on their own, and scale to our needs (s. Chapter 5).
For the most daunting problem of configuration management this means plugging some of those systems together and building a solution which generates and owns the full device configuration.
The automation will likely rely on multiple inputs to gain the full knowledge about the topology, operational overrides, subscribers and services, as well as rules to derive the configuration from all of that.
This is following the overarching goal to do as few configuration changes as possible and leverage protocols like BGP and BMP to extract/observe state, or manipulate device state where more dynamic changes are required.
This is the way
Having all of this in the cards the only API you need from a device is a function to upload a new complete configuration and let the device figure out the path from the current configuration to the new one.
Dealing with diverging configuration parts, across the fleet, carefully cleaning up old approaches to configure X, doing incremental changes, and figuring out how to interact with a platform API, a dialect of NETCONF, YANG, etc. would all be from the past –– wouldn’t that be great? I believe we are having a bright future ahead of us!
That’s where this great and inspiring book and Go come in! With Go you have a very solid foundation to build reliable, scalable and fairly easily testable and observable software, Prometheus integration is at your fingertips.
This way you can build tools to monitor your network (via BMP or streaming telemetry for example), inject routes via BGP, or build your own holistic network config generator an deployment pipeline as outlined above. Existing Open Source suites like Bio-Routing can help you on the first part (using BMP/RIS) and act as the foundation to, for example, build a route-injector following your business logic.
The fact that you are reading this indicates you are looking into building your own automation solution to tackle your organizations needs, that’s great! If you can, please share it as Open Source and present it a your local NOG — or VirtualNOG — so others can benefit and learn from it too, good luck!