Editor's Note: This article on DevOps is one of a set that can be found, along with videos and other resources, within the SDxCentral DevOps Topic. Check this Topic regularly to see the latest updates.

The idea that DevOps will accelerate change in the network is scary enough for many IT people. That those changes might be automated is downright horrifying. But what is the truth when it comes to DevOps and change control?

IT operations historically have adhered to the philosophy that maintaining stability=good, taking risks=bad. After all, the network is the center of everything: Servers, storage, and applications all plug into the network in some way, and the potential blast radius should anything go wrong is huge. Under the worst circumstances, an ill-conceived change can land your company on the front page of the Wall Street Journal.

But the methods and tools that reinforce stability today were developed in a different era. Today’s faster-paced business environment demands more responsive change control. DevOps practices can help IT professionals adapt the network to a rapidly changing environment while ensuring network reliability.

Are change control teams unduly concerned?

Even beyond the sheer reach of the network, the nature of networking changes are sometimes nigh impossible to explain. People who staff change control committees frequently are better versed in applications and servers than they are in networking.

And compared with server and application changes, which are generally well understood, networking concepts are alien to people who are not intimately familiar with how the network is architected. The result is a posture toward network change that borders on paranoid.

The truth is that network changes are, in fact, scary. Complex network changes frequently are done by hand. Node-by-node, operators log in, key in the changes, and push them live. Not only is the manual process prone to error, but if the change spans more than a few devices, it can be extremely time consuming to execute – or undo if anything goes wrong.

Changes are often quite complex, requiring every node to be perfectly configured for the entire system to function properly. Such a system cannot be verified until everything is complete, so troubleshooting along the way becomes difficult if not impossible.

Finally, there are the changes that touch dozens or even hundreds of devices. Going back to find the errant keystroke responsible for a problem can be difficult and time-consuming – and that assumes issues are discovered before users hit the network. For some changes, it isn't until the network is fully in use on Monday morning that the problems even arise.

Under these conditions it's not surprising that the best many of us can do is minimize the occurrence of change. But if the business demands a more responsive infrastructure, what are the alternatives

The DevOps approach to change control

DevOps already has proven to be an effective way of automating deployment and validation of server and application infrastructure. When expanded to the networking arena, it brings the same benefits of highly automatable and testable change.

DevOps is more than automation. Think of it as a framework bringing the disciplines of solid software development and managing infrastructure. Changes are literally codified so they can be documented, tested, and versioned before deployment. Because changes are atomic, engineers can undo wide-reaching sets of changes rapidly in the event of a failure.

The real effect of DevOps occurs well before changes ever hit the production environment. Imagine showing up to your change committee meeting with a description of the changes, the actual code highlighting what is different, a dependency map outlining the impacted systems, a suite of tests to validate the change, and a set of test results documenting the risk.

The automation that DevOps makes possible is balanced by the software framework that accompanies it. When developing a modern software application, it would be unconscionable to push code directly to production without first reviewing and testing it. IT infrastructure complexity rivals most commercial software applications and deserves the same level of rigor.

How can it be possible that the last line of defense between us and catastrophe is a manual review process staffed by people who might not even understand the network? The future of networking simply has to change, and DevOps provides the path for us to do it.