Csillia BessenyeiGuest blog by:
Csilla Bessenyei
Network Automation Engineer

Dozens of new articles are getting published about network automation or NetDevOps every week. There are more open source projects, tools, frameworks, SDN architectures, initiatives, and vendor solutions than I can count on my fingers and toes. Looking at the trends objectively: this really is happening. There is no question that network engineering and operation is being transformed as we speak. In this article I’d like to give an overview of some of the obvious benefits and perhaps not-so-obvious implications of this new trend.

Do It for Yourself, Not Just for Your Career

Anything new you learn is an investment in yourself. Learning network automation is a sensible move, but for the sake of “still having a job in five years” is hardly a reason which makes one excited. The most important thing to note here is that the above statement is based on fear. It’s a natural reaction to feel scared when changes happen. Five years is long enough to give you room to procrastinate. If you start next year, you still have four years, right? Getting out of the comfort zone is never easy, but you grow a lot in the process. Better start now.

Gaining confidence

In traditional networking roles, it’s not common to test every change before you implement it in the production environment. In this new paradigm you are better equipped to achieve this with carefully designed networks, production-like test networks, and proper tooling. Consistently configured networks are always simpler to manage and troubleshoot. No more “X did this config change and missed the ACL again” situation.

Automation scripts and tools are created in a development environment, then you test, test and test before you let it loose on (the subset of) your network. By running these over and over again, you will gain confidence that your automated changes do what they should. There is a lot to be learned from software developers, such as testing methods and the concept of CI/CD pipelines. Our domain – networks, systems, and coding – is all converging now. But testing software alone doesn’t mean the change has succeeded, only the logic for the code.

Validation of the change after it took place is also essential. You may have an initial thought: “It will not work” or “There are too many corner cases.” These can be transformed into the following questions: “How can I make it work?” “How can the design be simplified or constraints eliminated to make sure it works?” Or, “What data do I need to validate the outcome?”

Constant Learning

This path is far from easy and smooth. “No pain, no gain” they say. When you decide you’ll tackle a problem in an automated way, even if you are a seasoned developer, it is possible that you’re not yet familiar with a library or framework that you may end up using. Constant learning is key. Depending on the size of your project, new tools and features may be released after you started working on it. The whole process is a series of experiments, some of them will fail and some of them will allow you to move forward. This is a creative puzzle game, but sometimes finding the next piece is hard. You may go down rabbit holes, but you gain experience in the process and you may use this knowledge in the future. Although, I appreciate it’s not easy to look at the bright side when you try to solve a bug like this for 3 hours; “if (a = True) {} else {}”… Why does this condition never execute the else branch…
The experimental nature of this work brought back my childhood/teenage years when I was just hungry to play with technology for the sake of fun, such as installing various Linux distributions or just trying every WordArt possible.

The path to success is not always smooth

Accepting the truth: something will go wrong

The possibility of failure is not a foreign concept in networking. If it was, redundant topologies would not exist. The challenge with automation is to foresee where things can go wrong. To prepare for these cases we need to add more logic, code, tests, and error handling.
Building support systems, such as network source of truth (NSOT) or telemetry collection platforms, and populating them dynamically will help eliminate blind spots in the network where people have forgotten to add things.

When performing changes on a live network you must ask the question: “What can go wrong?” and then prepare for these cases. However, things might get missed or certain risks
have to be taken. Limiting the scope changes and the failures is a good practice , so if something goes bad, the problem will affect only a small portion of the network.

A few companies have introduced a blame-free culture. If there is a problem, they focus on resolving it and minimizing the chances of recurrence instead of spending time and energy on blaming somebody. It’s less likely that problems will be swept under the rug if there are no negative consequences for bringing them to surface.  Software, in the end of the day, is only as perfect as us humans.

Csilla Bessenyei presenting on network automation

My personal gain

Having greater freedom selecting or even creating the tools for my work can be described as “coming out from a closet and finding lots of new toys.” It gives me control, flexibility, and confidence that the problems I face can be solved, in many different ways.

Network automation, for me, is a constant loop of:

  • while true
  • being_in_comfort_zone()
  • something_needs_solving()
  • research()
  • experiment()
  • succeed() || cry_in_a_corner()
  • resolve_and_clean_up()

I highly recommend chatting with DevOps focused engineers or Site Reliability Engineers (SRE) and brainstorm about challenges that are frequent in our space. Network Automation is exciting, empowering, and opens up the silos. It allows us to deliver faster what the consumers of the network need – may they be our colleagues, the business, or our customers.

Although I started looking into network automation on my own, since then I found wonderful communities, where people are willing to help each other. Participating in these online and gathering-based communities helps me to stay focused and power my ‘hunger’ to keep on learning.

It is a great time to get started. There are tons of resources out there, so let’s automate all the things!

We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

Twitter @CiscoDevNet | Facebook | LinkedIn

Visit the new Developer Video Channel


Stuart Clark

Senior Developer Advocate Of Community, AWS