• 09/08/2015
    8:00 AM
  • Rating: 
    0 votes
    Vote up!
    Vote down!

The Need For Network Code Reviews

Network automation and orchestration will require standardization of the scripting used by network engineers.

While it’s true that network engineers and operators aren’t necessarily going to become app developers, it’s also true that most network professionals have been developing and using scripting for longer than DevOps or SDN has been a “thing” to be adopted.

Just about every network professional has at their fingertips (literally and figuratively) a toolbox of scripts they use to manage the various network devices and systems for which they are responsible. These are rarely documented anywhere and, truth be told, are often written using the networking pro's language of choice. Which may not be the same as the networker in the next cube, or the next cube, or that other cube, over there.  

At the same time,  enterprise organizations tend to force standardization of languages on developers. They also use coding standards and perform code reviews that are designed to not only enforce those standards, but to catch errors before they’re pushed into production. Network engineers, it’s likely fair to say, are not subjected to code reviews nor are they required to follow coding standards.

They should be.

Now, before you gesture angrily at the screen or utter a profanity a sailor would be proud of, let me say that standards and reviews are important. In fact, the 2014 State of Code Reviews Survey (yes, there is such a thing) noted that the top benefits of code reviews are improved quality (84%), ability to mentor less-tenured developers (62%), and enhanced maintainability of code (61%).

Read that list again, but this time replace “code” with “scripts” and “developers” with “network engineers.” Go ahead, I’ll wait.

It’s a nearly foregone conclusion that if the business (and by extension, the data center and the network) is going to scale in this modern, application-driven world, that automation and orchestration is a requirement. Not a nice to have, but a basic requirement. Certainly today both SDN and DevOps can operationalize deployment of network services and lead to lower operating costs, but that’s necessary in order to avoid skyrocketing costs in the future. The foundation of tomorrow has to be laid today, and that foundation is an agile, automated network service deployment strategy.

To achieve that without introducing chaos -- and thus a ton of architectural and technical debt that can constrain business growth and innovation --  there’s going to need to be more standardization of the scripting and systems used to automate and orchestrate the entire network stack. That means approaching these tools and toolsets with an eye toward consistency, which ultimately means there needs to be standards. And the way standards are enforced in code (whether formal or not) is through code reviews.

IT leaders, particularly those in areas that will be more affected by automation and orchestration -- operations and the network, initially -- should start an initiative now to catalog and understand the current skill sets with respect to scripting and systems used by engineers, architects, and operators in those IT groups. Once the current landscape is understood, a strategy for standardization can be formulated, including migrating those scripts and systems that may be implemented in non-standard languages.

And after that? It’s time for formal code reviews of existing scripts and a process for reviewing future ones.

The reality is that development methodologies and toolsets and frameworks like APIs and languages are rapidly becoming the mainstay for network operationalization. While it’s certainly pleasing to reap the benefits of efficiency and agility from taking advantage of the tools of their trade, it’s also important that network engineers adopt more of the culture and processes used to govern the use of those tools to ensure success and enable growth.


code reviews

Standardization and formal reviews of scripts used in networking makes a lot of sense, but will require a big culture shift. Lori, do you see anything that could help ease the transition?

Re: code reviews

To make the scripts more standard, it may be good to adopt a common model that describes the network devices. I know there's some attempt to do that in work for network configuration, such as for routing and BGP policy models in the openconfig working group.  That may enable scripts to be written in a conventional way that more people can unerstand.

Re: code reviews


A lot of that is easier said than done unfortunately today.

We've got so many different-different developers(each with their own style of doing things) Globally that its almost impossible to get everyone on the same Page(even if you try to standardize everything today).

A lot of folks will disagree with me here but 100% Standardization is totally ruled out unless you move to full 100% Code Generation Automation.

Even in that Sceanario,what is the guarantee that the folks who design the Automation Software all will be on entirely the same Page?

Interesting food for thought.

Is'nt it?



Re: code reviews

I agree that it's hard. Developers often want to do things in their own way. I was hoping that at last the data modelf for devices or protocols (switches/ports/routes) can be common, so that people recognize them as they port their code from one device to another, or rewrite code in another language (but still accomplishes same task).


For example, the browser documetn object model (DOM) is common and standardized, which made things easier for many developers.

But as you said, it's all an aspiration.

Re: code reviews


Yes about the only good thing I can say here is that the Aspiration continues to survive inspite of enormous pressures to the contrary.

I tend to personally believe if there are less people on the standards setting commitee who have hidden agendas of their own things tend to proceed much quicker when it comes to Standardisation.

Do you agree?


Re: code reviews

It's true that standards committees are where groups often fight and bring their own agendas.  But other areas are not perfect either.  In Open Source projects, people often fight and bring in allies to help their agendas too.

It's ideally supposed to be a meritocracy where the best ideas survive. I think that we had successes.  In general TCP/IP networks through the RFC process worked well, and although not perfect, we created a system that was more successful than their original designers expected. 

So I'm hopeful that if one works hard, you can get good results.  In general, having open reviews are better.


Need to bring unsupervised scripting to heel (unfortunately)

System administration scripting is a form of programming in place all around the data center, loosely administered, if at all, as Lori notes. It  may be painful but bringing it to heel will be a future data ceneter operations requirement.

Re: Need to bring unsupervised scripting to heel (unfortunately)


The Question that I am more interested in learning the answer to is primarily this-Who will bell the Cat here?

Who will be the first folks who will show the courage and patience neccesary to take such a drastic step(especially when your careers on the line)?

Its easy to ask for such a thing to be mandated in New datacentres but in older ones which could be 20-30 even 40 years old (parts of it) ;how will achieve that situation there?

Not easy.

Not easy at all.