Code Every Day. Or, what to do when the pressure to become a programmer looms like a cliff face while the storm of obsolescence closes in from behind…
Recently my daughter started learning piano. I’ve always wanted to learn, but found the prospect of concurrently reading the left- and right-hand parts too daunting. My daughter’s books managed to reduce that metaphorical cliff face to a manageable slope. One year later, we can both read and play simple tunes.
It’s the same with code. My team and I are not coders by background. We are network engineers at a research institute in London. Like many of you, we learned our trade through hard hours at the CLI. I’m sure I’m not the only engineer who has walked gingerly around a ‘learn to code’ lounge in a conference only feel overwhelmed and ill-equipped. If that is you, I encourage you to start anyway – you can do it. The best time to learn to code was twenty years ago; the second-best time is now!
But how? Well, two things got me over the cliff for the piano and for coding: an accessible resource, and the drive to play for ten minutes every day. I wanted to learn the piano with my little girl so that I could help and encourage her. I wanted to learn to code so that I could help and encourage my team. With this and future posts from that team, we hope to help others take their first steps and provide some fingerposts to ease the journey.
I may be laboring the metaphor, but I think Python is to network automation what the piano is to music. It’s universal, accessible, and you can do almost anything with it. I would also suggest that a good teacher will save you a lot of pain and bad habits.
We were looking at Ansible when I listened to Heavy Networking 445. This introduced me to Nornir – and an excellent online teacher. Kirk Byers’ extensive resources include a free Python Network Automation Course. A coworker and I both did our share of trawling w3schools, blogs, and other resources before discovering this one, I highly recommend PyNet.
Here is our approach to coding. The rest of this post will expand on it.
- Code every day
- Identify tasks best suited to machines
- Define the problem, then write useful software
- Use version control
- Make your repos public – safely
Code every day
Skill takes practice. Ten minutes a day is achievable and reaps significant benefit with musical instruments – far more than an hour once a week. Coding is the same. Good luck limiting yourself to ten minutes if you try this though, as coding is addictive!
Identify tasks best suited to machines
Some things are better done by hand. Some seem like they might be but aren’t. Some really shouldn’t be done by hand.
For instance, when rolling out 802.1X we did a lot of the early work by hand. Some of that was good as we were forced to go slow and work out the gotchas (Macs and Thunderbolt 3 docs don’t play nicely together). However, with hindsight, we should have developed a script to dynamically enable or disable .1x for a given VLAN on a device sooner. We reduced the final stage of our deployment from three months to one week by automating some of it, but that’s another story.
802.1X migration is quite a thing for the fledgling coder to take on, so we started with something less dangerous: SNMP config standardisation. Our network contains several classes of device, each with subtly different config schemas. These are maintained by hand. Humans are bad at doing this consistently; config-creep is a reality of artisan networks we could all do without.
Define the problem, then write useful software
We paused before rolling up our coding sleeves to check whether what we were about to write was worth writing. We asked questions like: Is there an existing open-source tool that would do the job well enough? What about commercial products? Is this the right problem to solve? Inconsistencies with SNMP were filed under ‘boring but important’ but I bumped it up to ‘do now’ because of the potential gains. I had no idea how far my team would run with this.
Problem Statement: Our SNMP config function is not standardised. Access lists are inconsistent and location data is mostly useless. We want to fix this and alert if a device goes out of compliance.
Ironically, our automation journey started with a tedious manual task. We audited our network and recorded the room, rack, and U number of each device. We then set ourselves the challenge of pushing out the correct SNMP config template for each device, with the correct SNMP location populated. You will be able to read about the journey in my coworker Paul’s ‘Network Borg’ blog here once it is published.
Our first candidate for a task better suited to machines is config standardisation. Our low-risk use-case is SNMP and our secret-sauce (which raises this problem above the mundane) is that we wish the SNMP location of each device to be unique. For sanity, we wish this location data to be stored in a single ‘variable’ file and the rest of our standard SNMP config (per device class) to be stored in a template file.
Once this code is written, we’ll be able to guarantee consistent state across our estate as well as easily and consistently change community strings, ACLs etc., across the board. NTP, AAA etc will surely follow and then we’ll wish to become all-powerful genies and, oh dear, I’m referencing Disney. Deep breath Guy, carry on.
We have a dev lab containing a few routers and used this to test our software. Proper testing increased our confidence. That said, we probably waited longer than we should to get our code into production. For us that means running it on a team server with an appropriate service account. The author ensures all dependencies are met so that anyone in the team can follow instructions and run the code.
It also means running our code against a production network. This sounds simple, but we spent some weeks psyching ourselves up to push out of first change using code. We came to realise it’s not so different from those brown-trousers cutovers we plan for over many weeks.
Use version control
We learned Git. For us, this was a no-brainer. Before using version control, I wasted many hours trying to unpick subtle bugs I’d added in some frenzied coding session. Now I can branch my code before going mad and easily roll back if needed. It also means I can collaborate on code with others. Github is brilliant and has simple tutorials. The paid Python Network Automation Course starts with an outstanding lesson on Git. My team spend time with other development teams and are working on a git handbook for our institute, covering both the why ‘this way’ and how of version control in our context.
Make your repos public – safely
Openness is one of my employers’ values. We’ve applied this to our code and will make our repos public as far as possible. I got the idea from the UK Ministry of Justice.
People tend to do better work when they know somebody will see the results. Musicians practice the harder, artists toil the longer, and novelists further refine their prose when they know their results will be seen. All bloggers know this.
Would Vivaldi have created the Four Seasons without an audience? Would the Mona Lisa smile so enigmatically had she always been destined for obscurity? Could my guitar heroes have created their most memorable solos as bedroom guitarists?
My public repo READMEs are rather better than the private ones.
Our Github is here. All of my team’s code is prepended with network_. We use .gitignore a lot and are currently actively working on a vault solution for sensitive data.
So that’s it. I hope this has been helpful to you. Please feel free to comment on or contribute to any of our code – be kind though, we’re new to this!
