In taking one last question for Q&A at the end of my talk on network reliability engineering (NRE), a plucky member of the audience shot up his hand. I remember he asked how he could possibly hope to achieve becoming a highly productive NRE. Because my talk had espoused applying the rigors of software engineering to NetOps, he wanted to know if becoming an NRE also meant becoming a master of programming, algorithms and software architecture.
I’d forgotten about this old question and my answer until recently exploring architectural discussions with @Mierdin about NRE Labs’ Antidote backend. In building NRE Labs there are material software architecture considerations to be made about drawing the lines in the project itself and its software pieces. Now if you’re an experienced software engineer or architect, you probably know these decisions are painstaking, especially in small software projects with ambitions to scale.
I suspect most readers here are experienced network engineers however. Maybe you have the same concern about getting into network automation and the seemingly tall order of software engineering. Will you need to deal with higher-order software design? Do you need to commit to a software engineering degree just to be a good NRE?
It may seem that because NRE implements software engineering methods, that learning software development and architecture is part and parcel. This seems daunting, but luckily it’s not necessary. Back on stage, when I answered, here’s how I looked at it.
First, Change Your Mind: Get Hacking
The software engineering task at hand for NREs should be much lighter and blithe than the crucible many full-time software developers face when they deal with complex programming and architectural challenges. Moreover, aspiring NREs should take heart in knowing that many professional software developers today have little formal training. Most of them are far from architecting software masterpieces, yet software teams achieve useful results without knowing the best architecture and programming patterns. The reason for this is because they build and refine with thorough change and testing pipelines for trying small, agile changes.
Their hacking attitude (i.e. just try it) is what most NREs ought try on for size. And of course, this means they have a “dev” playground environment, not only production.
Any networker with hesitation about taking the first step into automating, probably finds it impossible to attempt the hacking mentality if they lack the prerequisite dev environment—and most do. The good news is that today, you don’t need to build a physical lab or even your own virtual lab. Services like Juniper’s Cloud CCL can jumpstart a lab in no time. And even before that, anyone can freely use NRE Labs and experiment outside of the lesson plans. While lesson topologies are fixed, every time you enter an NRE Labs lesson, its virtual environment is your own private playground.
Before you get to continual improvement and the 5-step journey to automated NetOps, the most important step is the first decision to embrace the attitude of an automator and engineer. To start, change your attitude in just one small place. Perhaps even before you have a dev environment this could be as simple as: Never again will I manually check “> show…”
Remember that to begin the journey, there is no minimum amount of software engineering experience you need to change your mindset, so no excuses.
Next, Suit Up: Practical Software Engineering Tools for the NRE
Let’s get back to the question of how much software engineering is enough for an NRE in practice.
First, the specific methods of software engineering that an NRE employs are actually very mature well-documented processes for SREs and developers. The NRE is repurposing these processes for NetOps, and to shape such processes there is ample tooling for gitOps source code management, reviewing, pipelining, building, testing, deploying and verifying.
Learning the tools of the trade is not necessarily every NRE’s job. Like in software teams, people have specialties. If you’re a solo NRE, you can probably lean on software teams for help, but if you do truly learn this so-called DevOps toolchain, then you’re employability goes up tremendously, so there is good incentive.
Finally, the deployment, operation and care for the toolchain itself is all consumable as a service. At least at Juniper, we offer Testing as a Service (TaaS) and will bootstrap you or keep it running for you in Cloud CCL. With professional services, we can also help craft the specific tests and components you need to feed through Juniper’s Network Implementation and Test Automation (NITA) toolchain.
Finally, Focus on The Last Mile: You’re Closer Than You Think
Equipped with the right go-getter attitude and toolchain, it’s still important to understand the limited scope of the NRE: most of the automation—and hence software engineering effort—in a system should come from good software products and tools at the foundation. NREs are solving for the last-mile operational and integrational automation atop what are hopefully well-built network tools and systems like Junos OS and Contrail for Juniper customers.
Now, with the scope narrowed, with the help of tools, and with well-automated network systems, an NRE’s true building begins in automating NetOps. Building SLI-monitors, remediations, integrations, change workflows, tests, validations and perhaps chaos engineering experiments all sum up to the real the essence of an NRE’s creative software engineering work. The job here is really divided into crafting small automated tasks and “glue code.”
NREs are not building humongous software projects—rather the opposite. In fact, scripting, testing and programming the small NRE pieces are a very accessible introduction to software engineering. You don’t need to be an expert. You only need to be committed student. As Twain said, “continual improvement beats delayed perfection.” Start, and learn as you go.
image credit pixabay – geralt
