The death of network engineers; Long live network engineers

If datacenter switching is a well-served market for most customers, and the focus is then shifting (or has already shifted) to price and convenience, then we should see an increased customer focus on workflow integration. I am hardly Mikestradamus in predicting this; the DevOps movement has been well documented by tons of people.

As SDN and network virtualization continue to emerge, they promise a highly orchestrated, mostly automated network infrastructure. Who will develop the shim layers that glue all the constituent elements together? A new breed of IT engineer: the DevOps person. This DevOps person will be more programmer than specialized engineer, being skilled in Ruby or Python or whatever language and capable of developing the software connective tissue required to make good on all the promised OpEx savings.

I want to be clear about a couple of things here. First, the rise of DevOps is absolutely going to happen. When you try to connect individual components together, there is a need for an overarching architect who can see how these fit together. That skill set is non-trivial, and the software skills required to actually connect things goes well beyond the shell and Perl scripting that the vast majority of network engineers have in their toolboxes.

However, the theory that seems to be getting traction is that the rise of DevOps will signal the demise of the network engineer. Or you might hear about the power of overlays and how the network will be reduced to a bunch of static, dumb pipes that you build once and never touch again. But while this makes pretty good headlines, I think it is somewhat half-hearted analysis that leads to this conclusion. Let me explain…

Maybe 9 or 10 months ago, I was still at Juniper. A typical week included a lot of meetings, so when I had unexpected downtime, I would take it. One day, I was reading the newspaper in the break room for maybe 35-40 minutes. The break room had a couple of microwaves, one of which was broken. As I read the paper, four separate people came in to heat up food. I watched them all, one by one, as they put their food in, pushed some buttons, and realized the thing was broken. The first thing each one of them did? They reached for the power cord to see if it was plugged in.

When things break, the first thing we all instinctively do is check Layer 1. The orchestration and automation of IT infrastructure does nothing to change this. And to be able to effectively manage the underlying infrastructure, you need to know your way around a network. Put differently, I might know how to drive a car, and my GPS does a great job of telling me where to go, but when there is something wrong with my car, I still take it to an expert. This is one role of the network engineer.

Now I don’t want to suggest that the network engineer gets relegated to purely break-fix; this is just an example of why experts will always be needed.

Ultimately, both SDN and network virtualization are predicated on the existence of a functional network. They build on the network; they do not replace it. By managing policy more centrally, they make design and administration easier, but this alone doesn’t obviate the need for people who know how to build networks. Show me a company without network engineers, and I will show you a company that has completely outsourced its IT.

So does this mean I believe that network engineering will stay as it is?

Actually, I don’t. By pushing some of the policy and automation elsewhere, the network engineer should have an easier go of things. The extra time could be spent doing higher-order stuff (like acting in a DevOps role), or it could be spent doing more network engineering stuff. As networks grow (and all indication is that they are growing everywhere – and exponentially), this means that the ratio of devices to network engineer should become more favorable (the same number of people managing larger numbers of devices).

Doing the math on this, it is entirely possible that DevOps roles grow at the expense of network engineering roles as a percentage of total IT engineering positions. That is to say that more DevOps positions could be added over time than network engineering positions – at least for the foreseeable future. Note that I am talking about percentages here; if you were to look at just absolute numbers of each position, there will still be more network engineers AND the number of network engineers will grow, just at a lower rate than previously.

So where does this leave the network engineers of today?

There is a huge opportunity with the DevOps movement. If you are both an expert and a programmer, you will be in ridiculous demand. Folks that make this leap will stand to make a crazy amount of money as they will be in short supply. If you are only a DevOps person, you will find positions are plentiful as well. And if you are a more traditional network engineer, you will find that your job is still secure, and you will see that there are other opportunities also.

Demands on IT are increasing, folks. And the people who service IT demand will have a prosperous career. Regardless of what the headlines say.

Mike, your post seems (to me, at least) to echo what I posted recently on my blog: http://3fives.com/my-take-on-sdn/ You were just able to express my feelings much better than I was.

One certainly can’t downplay the importance that DevOps will have in our field in the coming years. It will be HUGE. But as I point out in my post, and you point out in yours, the DevOps will be made up of people who are FAR more skilled in programming languages than the average NetEng playing with Perl. The mantra of “learn to code or become obsolete” just seems silly to me.

I will never EVER be a skilled Ruby or Python programmer (nor do I really want to be). But to me, the decision to not hop on the DevOps bandwagon is no different from the decision to not hop on the voice bandwagon. Or the wireless bandwagon. DevOps will just be one more specialty available, that all of us may or may not be interested in.

I like framing the DevOps movement as a case for specialization. Gluing things together is, in fact, a specialized skill. As with any skills, those who are very early on in the movement will find that they are in demand and hence able to make it a lucrative career. But I don’t think that necessarily means that others have to lose for it to happen. I think some of the sensationalism around SDN is rubbing off a bit on some of the peripheral discussions. It’s good to keep things grounded.