One of the classic interview questions is “Where do you see yourself in five years?”
Discussions today with the delegates from Tech Field Day’s “Cisco Application Centric Infrastructure Launch” event led us to asking where the future lies for Network Engineers.
So what do you think you’ll be doing in five years?
Software/Hardware Defined Networking
Unless you’ve been hiding under a network-based rock or have otherwise been ‘off-net’, you can’t have failed to notice that the subject of Software Defined Networking has been coming up a lot. Many others are making the claim that, as network engineers, we all need to be learning Python if we want to stay in a job. Cisco’s Insieme announcements, while arguably tantamount in part to Hardware Defined Networking, doesn’t seem to change that. The argument is that network orchestration requires programming, so that’s where the future lies.
Once upon a time, I used to write documents using a pen and paper. Then I used a word processor (Wordwise Plus was my first I think, on the BBC Model B Microcomputer some time in the 1980s). Then with time and a job I migrated towards Wordperfect and finally Microsoft Word. Where once I had to get my hands dirty when I made a correction, I now just press a (backspace) key, and the correction happens magically.
But wait – the creation of the word processor effectively totally changed my writing process, and I had to learn a new skill (typing and editing on a computer). But did I have to learn how to write assembler or a higher level language? No, of course not; programmers did that, and I carried on with my creative process via the abstracted interface that is a word processor. You can see where I’m going with this, right?
We Will Not Program Networks
At least, I can’t imagine that I will. I’m most likely to rely on tools written by other people that will abstract the process of configuring the network in such a way that while I get all the gains of a highly flexible software-controlled network, I don’t actually have to write code to send bits and bytes to the end device. I don’t have to learn how to use an OVSDB module for Python in order to make this happen; I’m going to rely on somebody doing a darned good job writing far more reliable code than I can ever create, and doing far more clever things with the data it has than I can probably ever imagine.
I Just Talked Myself Out of a Job
There’s a problem here though. One of the examples I hear given often for how SDN will make the world a better place is provisioning. Right now the process of turning up a new switch port and VLAN is onerous and slow, and we network engineers (apparently) are slowing the whole company down and getting in the way. With an SDN-enabled network, we can click a few buttons and the job is done, without errors, in minutes.
So if a job that used to take me a couple of hours now takes me a couple of minutes, what do I do for the rest of the day? More to the point, if the software interface is so good at what it does that anybody can set up that interface, then why does the company need me any more? After all, I won’t need to know the CLI commands nor whatever method is used to configure that port; my specialist knowledge is unnecessary in this instance. So the provisioning jobs can be done by anybody straight out of school, and possible even earlier! So will deploying SDN effectively be the end of my own career? If so, what’s my motivation beyond an altruistic desire for the the general betterment of the network?
The CheckPoint Firewall Problem
I like pointy clicky interfaces up to a point, though I’m generally happier noodling around in a CLI. There are some tasks that do work better in a GUI though, so I’m willing to accept that sometimes they’re the better tool for the job. Personal preference aside though, I have a general problem with GUIs and it may sound a little bit snobby, but it’s this:
GUIs let people who don’t understand the technology think that they are capable of managing it.
Your honor, may I present Exhibit A,the CheckPoint Firewall. There’s nothing wrong with CheckPoint firewalls, nor am I suggesting that people who specialize(d) in configuring them were anything other than extremely bright people. However, who among us has not come across a few installations of a CheckPoint firewall at some point where the “administrator” was not a security engineer but a “Network Administrator” (i.e. server admin) who took on or was given the responsibility for the firewalls, and because it was a GUI, managed to somehow muddle their way through making traffic pass through. And when that happens, much of the time the resulting configuration is abominably insecure. I have, quite seriously, found a ‘permit any any’ equivalent at the top of an Internet firewall ruleset – with 200 rules below it – because all the admin knew was that it worked after he did that, and he stopped seeing “problems” after that. The “problems” were requests for new ports to be allowed through, reported as “Application X has stopped working” – yes, because there’s no rule for it. So that’s my problem. Had this been a PIX, the system admin would most likely have run a mile and brought in somebody who knew what they were doing. Add pointy clicky stuff to it, and suddenly everyone’s a security guru.
Security Engineers Aren’t Safe Either
Oh, were you smiling from your dark silos? Well don’t, because in the new world those firewalls you love may well be deployed on VMs and instantiated as needed by the network, with rule sets deployed and updated through another abstracted interface. Again, you probably won’t be programming that interface, just clicking “Approve/Deny” on the requests as they go past.
Rack and Stack
Don’t worry we still need you guys and gals. The one constant seems to be that there’s always new hardware to install, fibers to run, and cabling to check!
I Can Troubleshoot!
Perhaps that’s the purpose we’ll have in the new world. But then, in today’s Insieme presentation Cisco showed a screenshot of their (planned?) monitoring platform which included real-time application health and flow telemetry, including performance issues (latency, drops, etc.). If the management software can diagnose the nature and location of the problem, troubleshooting becomes unnecessary and all we’re left with is the corrective action. Mind you, a smart fabric will learn to route around problems where possible and will simply tell you that you need to check a fiber or replace a line card or something.
Five Years’ Time
So what do you think you’ll be doing in five years’ time? Ok, so as a reality check, smaller networks are less likely to have gone fully SDN I suspect, but medium to large enterprises and even service providers may well have gone partially or fully in that direction.
Assume for a moment that you work for a company that migrates entirely to some form of SDN platform with a nice clicky abstracted interface and strong orchestration processes.
What’s your job going to look like? Let me know; I seriously want to hear your opinions so I know whether to change career or not.
Update (11/7/2013): Please do check out my follow up post, where I drill down into some of the assumptions in this post and respond to some of the feedback I received.