Network Engineers: Don't Fear The Code

A common concern among network engineers as the beating of the DevOps drum gets louder is the associated focus on programmability. In particular, engineers are concerned they may be required to, well, code (rightly so, given phrases like "infrastructure as code"). They're concerned about the skills and skill sets they need that they may not have.

Certainly in DevOps, there is considerable focus on automation, which is based on code. Continuous delivery is slowly but surely pushing its way outside of dev and ops and into the network, and seems destined to push code along with it as well.

But let's stop for a minute and consider what is meant by "infrastructure as code."

The concept is more a neologistic metaphor along the lines of "technical debt" than it is a statement of fact. The concept is trying to introduce the use of configuration management and release schedules and automated roll outs as much as it is introducing the use of code to accomplish these tasks.

Most network engineers are already familiar with scripting. Whether it's Python or PERL, Bash or some CURL, network engineers know how to script common tasks across a variety of devices. The extensions DevOps tries to bring when it says "infrastructure is code" is that those scripts might be stored in Git, where they are versioned and controlled. There might be templates such as those associated with Puppet or Chef (manifests and recipes) that, too, are stored in Git until they are pulled and pushed during a deployment cycle.

This is not "code" as a developer would define it (and I say that as both a developer and a network admin) but rather the treatment of network configuration artifacts as if they were code.

Does that require some new skills? Perhaps. But it leverages existing ones, too, and relies on the knowledge and skills network engineers already have. After all, someone has to know how to block traffic on port 8080 on (insert favorite vendor here) switching infrastructure before it can be scripted and automatically deployed.  

The reality is that the amount of coding you do now  is likely as much as you'll be asked to do when DevOps finally reaches your door.  Scripting is the lingua franca of DevOps and scripting is something that most -- if not all -- network engineers are fully capable of and exploit today. Still, that doesn't mean you won't have to learn things.

In particular, there are a lot of other things that go into DevOps that aren't covered by code, such as simply optimizing processes and decomposing infrastructure. There's figuring out what (and how) you need to measure in order to meet the business priorities that are driving DevOps in the first place: faster time to market, reduced risk and lower costs.

You can hear more about these topics at Interop Las Vegas this spring, where I'll lead a workshop with consultant John Willis and Jeremy Schulman of Schprokits, Achieving Operational Excellence Through DevOps. We'll provide guidance on how to get started operationalizing application deployments.

Register now for Interop, April 27 to May 1, and receive $200 off.