Is DevOps just for the abstracted parts of the data center?

It’s relatively easy to come up with ideas for applying DevOps principles to things such as operating system builds, storage provisioning, and server blade provisioning. It’s common to see virtualized environments managed by tools such as Puppet and Chef.

What about networks? Not just virtualized resources, but the good old fashioned top of the rack switches that aren’t managed by network controllers? Can mundane or even complex tasks be automated with solutions such as Chef and Puppet and tested using configuration management tools such as Ansible?

Earlier this year, I got the chance to sit down with network engineer Matt Oswalt and talk through an operating model in which an organization could leverage DevOps approaches to automate network changes. In this post, I’ll recap the use case.

The challenge

Common changes are a constant challenge for network operating teams. How to request, test, implement, and document changes in a small network are a challenge. The larger the network, the more difficult the challenge. Change management and implementation are a common pain point for cloud implementations.

One of the simple use cases I talked through with Oswalt is a VLAN change. While the commands to perform a change are simple, there are many considerations in making the change. For example:

  1. What devices should receive the new VLAN, and how do you push the change to multiple devices?
  2. At the end of the change, how do you validate the change was successful and document the new network configuration?

While the change is simple, it may take a senior engineer to implement the change due to the complexity of the manual process.

The DevOps approach

Oswalt proposed a system in which junior engineers can leverage DevOps tools to execute changes. In Matt’s proposed approach, senior network engineers would create common workflows that could be tested for compliance and implemented using automation tools. The output of the tests and implementation scripts transfer to a configuration management system.

At a high-level this all makes sense. As the saying goes, the devil is in the details. What knowledge is required by the senior network engineers to implement such a system? Would an organization need to engage consultants in building the workflows?

I also had questions about the maintenance of the automation platform post implementation–would an organization trade one set of complexity for another?

Capability enablement

Oswalt challenged me on one core concept that I tend to concede. An organization has to make investments when considering the implementation of any DevOps-powered solution. The ultimate goal is to create capability and value where it was nonexistent.

The point of Oswalt’s use case was the ability to expose net new capability. Not only does the above use case free senior resources, but the organization also has software enabled a workflow that required manual intervention. Matt has already provided the basic building blocks for implementation of a similar process, and Matt has created a project to auto-deploy configuration using Ansible and Jenkins on his blog.

Looking ahead

There’s no doubt that network engineers would need some new scripting skill to implement and support a DevOps-powered workflow. However, there’s an argument that the investment creates value today and provides a foundation for supporting a software defined network environment in the future.

What do you think?

Does the approach described by Oswalt resonate? Do you see the effort as worthwhile? Share you comments in the section below.