CAREERS

  • 03/02/2015
    8:00 AM
  • Rating: 
    0 votes
    +
    Vote up!
    -
    Vote down!

Network Engineers: Don't Fear The Code

The DevOps focus on automation and coding is pushing its way into networks, making network engineers uneasy about learning new skills. But a closer look at the trend shows it's more about the scripting they already do.

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.


Comments

automation

Lori, thanks for putting DevOps/automation/coding into perspective here. I think it should go a long way in easing network enginers' anxieties about the changes ahead in networking.

Re: automation

"I think it should go a long way in easing network enginers' anxieties about the changes ahead in networking."

Marcia, you are right. Changes and adoption of new technologies are frequent and that too before get familiarizing with the existing one.  So such anxieties are more with networking engineers.

Re: automation

Hi, Mynet!

Change is always scary. Well, it can be exciting, too. But, I understand how network engineers can feel anxious about changes in the networking scene. When you say changes, it means you are to expect something new; something different. Change is not bad, but if it comes too fast, then the feeling of anxiety is validated. Especially when you're dealing with something that's quite complex, like networking. It (frequent changes and upgrades) may already be a common process in the world of technology, so maybe our network engineers already have an inkling of what they need to do (not "per se", though): study, explore, and adopt. Easier said than done, I know; but it can be done. J

Re: automation

"Change is always scary. Well, it can be exciting, too. But, I understand how network engineers can feel anxious about changes in the networking scene. When you say changes, it means you are to expect something new; something different. Change is not bad, but if it comes too fast, then the feeling of anxiety is validated. Especially when you're dealing with something that's quite complex, like networking."

Sherly, things can be bit complex and scary; but we have to face it. Technology advancement is for better enhancement and we have to make use of it. 

Interop technical sections

"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."

Lori, can we have some update about this event, through our community. If you are able to share then it will be helpful for non attendees.