Network Testing Gets Easier With DevOps

When we hear about integrating DevOps approaches to managing network infrastructure, what is usually being said is something about network automation. And, more directly, it often boils down to a configuration management tool such as Puppet, Chef, or Ansible. While this is an amazing step forward for an industry in which CLI is used daily by most network operators, there is much more that we can learn from those who have implemented DevOps methodologies and technologies over the past several years.

If you talk to any systems administrator that is actively implementing DevOps methodologies using Puppet, Chef, or an equivalent, you'll find there are significantly more tools in their tool belt that make what they do possible.

You'll hear about the role of Linux, the value of version control systems like git, how they actively test using systems like Jenkins and Travis, and the direction they are taking to adopt immutable infrastructure using container technologies like Docker. It's very evident that DevOps, even from a pure technology and tools perspective, is much more than configuration management.

It would also not be possible for systems administrators and application developers to make as many successful changes to their application infrastructure if they did not have a solid test harness. Tests start with unit tests that test the code being written, but go on to test the actual deployment process --- think systems and integration tests. How is this achievable? They spend the time up front to understand what needs to be tested whenever there is any change to their code and system! And it helps that they are using portable virtual machines and containers they can rapidly spin up and down for testing.

Okay, so how does all of this relate back to the network? More specifically, how does this map back to running automated tests on network infrastructure?

Let's see by thinking about these questions:

Just by reading those questions, you probably know networks could be managed more efficiently, and hopefully you can start to see that there is much more to DevOps for Networking than automating configuration management. And -- more importantly -- you should realize that you can adopt automation without actually pushing a change to a network device.

Learn more about DevOps, automation, and network testing at the DevOps for Networking Summit led by Jason Edelman, Founder of Network to Code, at Interop Las Vegas this spring. Don't miss out! Register now for Interop, May 2-6, and receive $200 off.

A great starting point for integrating the network into a DevOps-style workflow is automating the process of pre- and post-change validation. It is 2016. You should not be saving the output of show commands in Notepad, examining them manually, and having them go rotten on your local hard drive. The comparisons and validations should be automated, providing you with the change deltas instantaneously with the final outputs versioned and tracked, leveraging a version control system.

► Note: The pre- and post-change validation process, along with automated tests, could happen before changes are performed with any form of automation. So, yes, it's true, you can still make manual changes, but also take advantage and gain the assurance that the change was successful by automating the testing process.

As networks are built out in a more software-centric model, the test process will get easier for all of us. For example, after you submit a change to make on the network, automated tests should kick off. These should first validate it's a valid configuration, and then go on to load the new change/config onto a set of test devices (or nodes). Beyond that, more robust tests could be run to validate policy, end-to-end reachability, and so forth.

The ideal test device platforms are software-based -- it's not realistic to have a full replica of a physical network. As part of a test harness for networking, we need to be able to spin up on-demand virtual networks -- anything from virtual-machine-based firewalls and switches to container-based load balancers -- perform the required tests, and then de-commission them. This will come with time, but even if the virtual test network is static, it's a huge step in the right direction.

Does this sound great, but you don't know where to get started? First and foremost, you need to know what to test! That means to start documenting workflows and test patterns immediately, and before you touch any new tool. For more, come learn from real-life practitioners at the Interop DevOps for Networking Summit on May 2.