Does SDN Mean IT Will Be Able to Get Rid of Network People?

Over the last several months, Greg and I have talked a lot about software defined networking. SDN is a new and interesting way to look at moving traffic around a network. In fairness, some would argue that SDN is not “new” as such, but I think almost everyone would agree that it’s interesting. Yes, even those of you who are sick of hearing about SDN. SDN seems to strike fear into the hearts of network engineers just getting started in their careers. “The world is changing,” they – and perhaps you – reason. “Is there any point in going after networking certifications? Or being in networking at all?”

By way of example, missives like the following grace the podcast inbox from time to time. (Identity of the sender kept anonymous at their request.)

I was listening to Show 112 and the other SDN shows, and you are making me worry.  I got my (standard) CCNA last year, and am working towards a few more certifications this year.  Now with all this talk about SDN, is IT going to need as many ‘network people’ in the future?

I mostly do desktop support right now (have been for about 8 years now), and hope to move into doing more network type stuff at the enterprise where I am employed.  What I wonder is maybe within 5 years where each site for my company has at least one network person, will one network person be able to support all of our sites?  Right now, the company has about 15, maybe 20 network people spread around the state.

Therefore, what I wonder, do you think there will be continued growth for CCNP, and CCIE type people over the long run?  Or might SDN technology more or less put these type of technology people out of work…  And that would leave CCNA type people to rack switches/routers, plug-in cables then call the one CCIE for the whole enterprise and say ‘ok, can you ping it’?

Should maybe I give up on networking infrastructure and look into moving to servers and virtualization (shutter the thought)?  I don’t want to get to be a CCNP in a few years, only to have that kind of work ‘replaced by a machine’…

My short answer to the concerns raised here is that networking folks haven’t got a thing to worry about. Sharp network folks at all levels of ability and experience will always be employable, even in the coming SDN netpocalypse. More than that, I don’t think SDN will enable IT organizations to shed network staff members. As my friend Tony Mattke is fond of saying, “Complexity goes against robustness.” And software defined networks will inevitably be complex. SDN does nothing to make networks simpler – not down underneath, not down where it counts. They are every bit as complex as legacy traditional network are today; I could argue that they are more so. With complexity comes things not working right. And when things don’t work right, it will take someone who knows where their towel is to make it better.

And that’s us. The packet militia. The hardcore, stone-cold, heroes of the keyboard armed with sniffers, cluebats, and whiteboard markers. Yeah. The network engineers.

That was all very rah-rah…I know. So now for the longer answer…

Question 1 - With all this talk about SDN, is IT going to need as many ‘network people’ in the future?

As I mentioned above, my opinion is yes. The only specific burden I see SDN alleviating is that of rudimentary, day-to-day provisioning. And even that’s a stretch. Why? Because we have the ability with SNMP, expect, NETCONF/YANG, and APIs to automate network provisioning in a way that integrates with server provisioning, and we have for years. And yet, on the whole, there’s still not much of it going on. Or if there is, the provisioning is a part of workflow process that still involves human beings to review and approve – humans that need to know what they are looking at.

Also understand that server and virtualization people are not network people. Yes, there are smart folks in that realm like Scott Lowe (you do read his excellent blog, don’t you?) who are wrapping their brains around new network technology, but networking is a complex, detail-oriented, technical discipline. Just like virtualization is. And just like storage is. Etc. It is becoming increasingly difficult for any of us to be very good at more than one discipline, because it’s challenging enough to keep up with our own. As the problems unique to each discipline are increasingly complex, so are the solutions.

In my experience, server and virtualization guys are often stumped almost immediately when their system can’t communicate, and usually the issue is no more complicated than a bad VLAN tag. Do we think a complex connectivity overlay generated by an SDN bathed in unicorn tears is going to suddenly imbue those guys with the knowledge requisite to successfully troubleshoot a problem? In the words of John Pinette, “I say nay nay.”

Question 2 – Will SDN enable one network person to be able to support far more sites than today?

Not very likely. To my mind, SDN’s big promise isn’t that of fewer staff people. It is (potentially) faster time to bring network services online and dynamic reaction to changing conditions. In other words, SDN will add new and rich functionality, as opposed to replacing people who do mundane networking tasks. Not to beat a dead unicorn, but the richer that functionality becomes, the more human firepower that will be required to make it work right.

Question 3 – Do you think there will be continued growth for CCNPs and CCIEs over the long run?

Yes…although I think the sorts of skills that are taught in the CCNP and various CCIE tracks are going to expand from what they are today. Note that I said “expand” and not “change”. IP networking is still IP networking. IPv4 will be around for a long time. IPv6 is growing rapidly. Ethernet is the default transport, and the roadmap for Ethernet is long indeed. Switching and routing is still switching and routing. Those networking fundamentals will serve you well for the long haul, no matter if vendors decide to replace OSPF and BGP with some fancy new protocol to make forwarding decisions.

Therefore, dig in. Get certified on Juniper, Cisco, whatever. But then keep learning. One of the themes that comes up in SDN discussions is that of network programmability…using APIs to program network devices instead of the CLI. If you know how to do scripting and/or honest-to-goodness programming, I believe that this skill will probably serve you well in the networking industry. We’ll see how this develops over the next several years, but if you don’t know how to read & write code, start learning.

Question 4 - Should maybe I give up on networking infrastructure and look into moving to servers and virtualization?

Now, that’s an interesting question. If you’ve read this far, you know what I think the outlook is for network engineers in light of SDN. So obviously, no, I wouldn’t give up on the networking side of things. However, if you want to augment what you do, virtualization is, in my opinion, the absolute next best tech to get a handle on. Why? Network infrastructure is being virtualized. Part of SDN’s promise is to abstract physical network devices and treat the network as a virtual entity. Plus, there’s an interesting array of virtualized network appliances out there. Understanding hypervisors and how packets flow around them is a critically useful skill to have as a network engineer (something I’m still working on myself), and there’s a lot to know. As you start digging into this topic, you’ll find that there’s no one way every vendor handles their virtual switches, security between guest OS’s, etc. It’s a huge topic, but one that will make you exponentially more valuable to IT organizations as you learn it.

In summary, I wouldn’t move over to virtualization full-time, but I would dig into the networking side of virtualized infrastructures. Maybe add to your CCNP or CCIE a VCP.

Stay The Course

Change is here in the networking industry. Change isn’t on its way real soon now. It’s here. Pay attention to what’s going on, and keep your skills up to date as best as you can. Understand the problems that new technology is trying to solve – understanding the problem will go a very long way to helping you understand the technology in play. Networking isn’t about provisioning VLANs, adding routes,or turning up interfaces. It’s about getting traffic from one place to another quickly, reliably, and securely. If the task involved to facilitate that happens to be provisioning a new VLAN, so be it. But if that task turns into writing a script that an automated provisioning task calls when a new VM gets spun up, be okay with that, too.

We don’t know where SDN is going to take us yet, and SDN has gotten far more media attention than market adoption. The best thing you can do is stay on top of what’s happening, and in the meantime, stay the course.