What SDN Could Mean for Networking Careers in One Picture


Software defined networking (SDN) has caused many network engineers to ask the question, “Will I have a job in the future?” I believe that everyone who is willing to stay current and update their skills will forever be employed. The key is staying current. What does that mean, exactly? I have a post coming about that, but for now I spied this picture. I think it captures some of what I believe will happen over the next several years.


When it comes to running your network, be the one controlling the tools. Don’t let your usefulness fade so that you’re of no more value than the tools themselves. If you’re simply a tool that can input commands into a CLI, then eventually, you will be replaced by something faster, less error-prone, and tightly integrated into a much larger IT engine.

About the author

Ethan Banks

Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.


  • Ethan this is great start to this conversation. Is the network engineer going to buyable job in next years to come. I believe what is missing is a true conversations from engineers to future engineers with career example and business examples that engage us. Multiple examples & guest from the past when change occurred and how they handled the changes. I would pull this into multiple podcasts at Packet pushers because this will bring the Networking community together.


  • Great picture. But a short-sighted view IMHO. If you KNOW what you are doing, then you are a conductor (orchestrator?) regardless of whether we are calling it SDN.

    If you don’t know, then you just follow directions and see little pieces. And you are the tool.

    That holds true irregardless of the introduction of am automation technology. Progress.


    • Fair (and I agree, actually), but not the point I was making. Or failing to make? ;-) I’m trying to get people to think ahead and realize that the CLI has alternatives getting a lot of traction for very good reasons. If the CLI remains the only way an engineer comprehends interacting with the network (true for many), then there’s a long term problem for that individual.

  • I’m currently in a large environment that is beginning to embrace SDN concepts for traffic monitoring & analysis, TAP’s and other neat functions.

    We already have;

    1. Monitoring – SNMP, Netflow, Syslogging, Remote Script Execution & Automation
    2. Analysis – TAP’s, Remote Probes and of course – Techs who have laptops, wshark
    3. Troubleshooting – Series of .py and powershell scripts to cut the time down 10x.
    4. Implementation – Flat, Standardized, Automated (DHCP & Boot) deployments.

    I haven’t touched my CLI for a good 7 months. We use intelligent programs, scripts and tools in orchestration with existing control plan protocols like OSPF, IS-IS, MST, TRILL, etc. to re-direct traffic, react in disaster recovery situations and provide visibility.

    2 years ago, it was 3 guys buried under water in break-fix situations (10,000’s of nodes around the world, just L2 and L3), now we’re a team of 5 taking on multiple projects, lab validations, designs, deployments and even technologies (Think DevOps, Virtualization and Server Tinkering). We’ve HIRED more people, doing less hours (meaning, not 50-60 a week but 40. :) ), utilizing that time more creatively.

    SDN technologies and like-concepts already exist, and will continue to add extremely useful efficiency, visibility and capability to the network. Our purpose is to understand, develop, optimize and expand Network Services & Network Infrastructure. We’re a business unit serving a business case, not command line warriors. We’re not supposed to be platform experts, we’re supposed to be TECHNOLOGY experts.

    When the tools, orchestration, scripts, etc. break, bug out or don’t work – you’ll need a Network Warrior who knows the RFC’s better than their wives birthdays. Given the track record many of our Linux & Windows counterparts have experienced, you can expect it.

    My 2 Cents.

    • ‘We’re not supposed to be platform experts, we’re supposed to be TECHNOLOGY experts’.

      Unless you are actually working inside the R&D dept of a technology vendor you are NOT a technology expert and a platform expert is what you must become.

      Unfortunately, network pros have a poor habit of viewing their preferred vendor boxes as platforms, when its just one of three common infrastructure elements that make up an overall technology platform that can have a many constituients.

      Platform expertise will involve the integration of the right hardware and software infrastructure components to support and deliver the business applications, technology experts will support platform experts by producing products that help simplify these integration tasks.

  • What I see is whether you are going for NSX or ACI….Manual coding will be a thing fo the past and Apps define and deploying network changes dynamically will be the norm.

    ACI is also a fully automated tool and theres no scope for any dammned CCIE or even a L2 Network engg to it.

    That Said, CCIEs will be required more in Future as SDN flies oof COZ…COZ…COZ…

    1. Dont expect SDN networks to fully auto-heal all by themselves…You still need engineers who can uderstand whats happening beneath…

    2. Having a GUI tool and that too an automated one is ……like..e.r umm….making Enggs Lazy….Most of them think what they see and can do with the GUI is thats it…As on date, as far as the VM experts are there, there are very few, a handful who are truly experts in SAN/VM etc…most just know to click here and there and thats it…Most involve the Vendor TAC for tshooting hidden issues….Many SAN guys dont even know how to fix slowness issues on thier SAN…God save an SDN network thats setup on an ill-done SAN….

    This is WHERE our CLI minded CCIEs will be of use… even thought CCIE and SAN having nothing in common…the MIND is the difference…CCIEs will SHINE when they get themselves on SAN/VMWARE NSX….My Advice is…
    Do CCIE..
    Dont stop at CCIE….go fully into NSX, ACI, VM, Storage…become a Cloud architect.
    Understand the differences between NSX and ACI and recommened each where appropriate. I beleive ACI will have its own market if/when Cisco Delvieres it fully…

    And…whenever the VM geek in your company quits, offer your services to replace his role…
    Meaning…Network guys have the leverage to become fully converged than VM/Storage guys…
    DO it qwuick and learn fast,,,

  • okay, and someone tell me , how adding SDN skills to my skillset translates in terms of more $$$ ?

    • HA! Nothing will magically translate into $$. It’ll depend greatly on where you are and what you plan on doing with it!

      New (cutting edge?) skills are adopted in limited segments. But if you are in those segments you can capitalize on them well. Hard work was never easy though!


Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.

Subscribe via Email

Receive complete, ad-free posts in your inbox as I publish them here.