Building network automation solutions

9 module online course

Start now!

Network Reliability Engineering Should Be More than Software or Automation

This blog post was initially sent to the subscribers of my SDN and Network Automation mailing list. Subscribe here.

In late 2018 Juniper started aggressively promoting Network Reliability Engineering - the networking variant of concepts of software-driven operations derived from GIFEE SRE concept (because it must make perfect sense to mimic whatever Google is doing, right?).

There’s nothing wrong with promoting network automation, or infrastructure-as-code concepts, and Matt Oswalt and his team did an awesome job with NRE Labs (huge “Thank you!” to whoever is financing them), but is that really all NRE should be?

Just looking at the acronym it has three words in it:

  • Network (ok, we know what this is)
  • Reliability (tougher one, ask network practitioners how to calculate reliability of a complex system and watch them squirm)
  • Engineering (you probably know my opinion about this one).

Reliability Engineering is also a well-defined concept, and one would assume that Network Reliability Engineering applies that concept to computer networks. Really?

While I totally agree we need to replace repetitive (and error-prone) manual operations with repeatable automated processes, I also believe you should not automate existing mess, but start with a reliable minimalistic network design without one-off exceptions and gazillion of configuration drifts caused by late-night throwing-spaghetti-at-walls google-and-paste troubleshooting sessions.

Unfortunately (as I pointed out in the podcast I did with Matt a long while ago) the NRE blog as well as Juniper whitepapers and marketing collaterals keep mum about that aspect of network reliability and focus on workflows and automation (no surprise there, Juniper is doing a really good job there).

So, what do you think? Am I too radical, or should we start with a thorough cleanup (assuming you’re dealing with a brownfield environment) and reliable designs instead of rushing head-on into automating whatever we’re doing?

It seems Russ White might be thinking along the same lines (here’s another article he wrote)… but maybe we’re just a bunch of grumpy oldtimers.

Finally, have to mention that we cover what might be a more reasoned approach in the getting started module of Building Network Automation Solutions online course ;)

Add comment
Sidebar