Must Read: Network Engineer Persona
David Gee (whom I finally met in person during recent ipSpace.net Summit) published a fantastic series of articles on what someone bringing together networking, development and automation should know and do.
- Part 1: Evolution of roles and the gaps
- Part 2: You don’t have to be a developer
- Part 3: Be agnostic, figure out the requirements, select the right tools
- Part 4: Understand logging, embrace success and failure, understand the programmatic interfaces
Apart from being an awesome read, it was really nice to see how his conclusions match almost exactly what I’ve been telling attendees in the introductory sections of Building Network Automation Solutions online course.
To me, this is nothing new. I have been involved in networking and IT long enough to spot re-circulating ideas and the latest fads. Fundamentally we are
trying to describe a workflow, whether it be using JCL (remember those mainframes) or bash (early UNIX) or ansible/salt (the latest and greatest). It doesn't matter whether
you come from a UNIX systems admin background or a networking one, you are trying to visualise a series of steps/commands/phases that will get you from start to finish
for a particular requirement i.e. build me a 3-tier web-app.
Back in the day (not too long ago) I used TCL and expect as the tools of choice to achieve my aim and they worked pretty well. Today, the choice is python and REST/APIs which you could say
is a natural progression.
My main issue is with applicability. Hyperscale companies such as Google and Facebook have significantly different issues to solve compared with your average small to medium
enterprise, and yet the media dictate that automation is the path to follow in all cases.
When it comes to development then I agree that advances in virtualisation have enabled development teams to provision target environments quick and on-demand
and this assists in their efforts to be agile, however, once that application is released into production, the networking element becomes pretty much static
and adopting an agile/automated approach to networking does not yield any particular benefits in my opinion.
The main cause of delay to any application roll-out will always be the development effort. The reason networking always seems to be sited as a delay is due to time it takes to include
the relevant resource in the overall project plan. In my experience, the networking guy is always included at the last minute and then introduces further delay by
asking pertinent questions that should have been addressed much earlier in the process.
It is all about communication.
Is there a role for a network automation engineer in every company, I would say NO. Is there a role for a jack of all trades who understands the company and
and will apply optimisations as required, I would say YES. What would they be called? Well an infrastructure engineer springs to mind.
As for "Is there a role for a network automation engineer in every company, I would say NO." I disagree (unless we're talking about really small companies). However, she doesn't have to focus exclusively on network automation, but on getting repetitive things (whatever they are) done consistently, reliably, and eventually faster. Agree? Disagree?