This article is number two in a series. The first part can be found here.
There has been a thought trend in the last few years leading network engineers to think they need to be developers. This is totally nonsense. When we want to learn a new skill, there is a precursor which says “I want to do X, so therefore I need to learn about what X”. If you’re thinking “I should be learning Python”, I ask to what goal? What is making you ask this question? Maybe the question should be, for a network automation engineer role, what skills do I need to learn? Stop guessing!
The Network Automation Engineer role combines deep network knowledge, with the ability to describe, collect and transmit domain specific data through one or more abstraction layer type components. It requires knowledge of how to collect data from databases and data-stores of various types. Where does a list of IP addresses get stored? How are they stored? How are they retrieved? The role requires an awareness of the cause for making a change and the implication of making them. Gaining the skills to become this persona isn’t a full career change, but a set of additional learnings if you are already a network engineer. Put another way, it’s one version of an upgrade pack to the trusty network engineer persona.
What if you are a software developer wanting different challenges? Does the same still apply? If you have the appetite to learn networking up to a professional level, then you can take your developer brain and experience with you on this journey. You will also require empathy for the issues and mechanical sympathy for the problems, as wiping the slate clean and starting again isn’t an option for production infrastructure (normally). It’s a game of progression!
The Problem With Human Beans
Solving the ‘volume of changes’ problem requires a different approach to just adding humans and expecting things to scale up. Homo sapiens (or “human beans” as my old physics teacher used to say) have a limited throughput and amount of RAM. Our brain waves operate in the 0-100Hz range (absolute minimum and maximum values for five types) and physically we’re not exactly capable of catching bullets or breaking the “sound barrier” from typing quickly. Our volatile memory isn’t as good as RAM. Just because our eyes are open, it does not mean we can retain the content of a book by scanning over the pages, until we go to sleep and power down. We have limits. Despite our slow brain waves, we can achieve an enormous amount. Science today is trying to unlock the magic of the brain, yet, given this tremendous organ we call our mind, we can only do and contemplate so much in a given time domain.
If our brain and physical form can only handle so much, simple and humanistic automation is the first answer to handling demand. As humans we can automate things humans would have previously have done. This doesn’t involve replacing the network with OpenFlow capable devices or programmable pipelines that only network skilled software developers can handle.
Whilst “Knowledge Defined Networking” or “Machine Learning Driven Intent Based Networking” potentially removes our automation panacea (meaning: automating tasks a human would do in a human way), we’re not quite at the point where we can throw network devices together and expect a boring “it works” outcome.
Skills To Focus On
Good automation tooling give us the ability to generate codified flowcharts that take inputs and deal with the ‘how’ in a layered way. It’s about data flowing through our mental flowcharts and what we do with it. I recently wrote another article describing this declarative and imperative thinking.
On solid foundations, great things can be constructed. As a network engineer who has mastered IP, Ethernet and routing protocols, society has not only made your job harder, it has gifted you empty slots, which can be filled with automation skills.
The next article focusses on skills that you might want to learn to start or progress your journey towards being the “network automation engineer” person in your organisation. These skills are generic, agnostic and flexible enough for approach based on logic and common sense.
If you want to read on, here is part three.