SDN Isn’t Kryptonite To The Network Engineer

May 26th, 2013

Sometimes a picture is worth more than a 1000 word response to articles like this:


Translation: SDN (Automation, overlays, etc.) is wholly dependent on a well designed and deployed physical network. SDN can provide very useful features and capabilities…again, when deployed on top of a well designed and deployed physical network.

‘Automating’ means pushing the big red easy button. However, the “big red easy button for networking” only works because someone WELL versed in network design and configuration pre-configured it for the button pusher. Automating the configuration of applications and associated services requires the proper chaining together of required, and properly configured, physical and/or virtual resources. Automation doesn’t remove initial complexity. Automation helps reduce perpetual complexity – design once, use many.

Network engineers are needed for proper design and deployment of a solid physical network. Network engineers are needed for designing service chaining required for things like automation. And network engineers are needed when things break.

For the network engineer, SDN simply means that they will need to add things like python to their skillset. They need not worry about the future of their existence.

May 26th, 2013 | Posted in Networking
Tags: , , ,
  • Bradley777

    Funny post Sean. But I can’t help but to observe just a wee bit of irony here. It was the Easy Button to disrupt servers with automation, but now it’s a Not So Easy button when the automation disrupts the network.

    • M. Sean McGee

      Hey Brad! Good to hear from you, bro.

      During the 2+ years that you preached the glories of UCS, did you ever sell Service Profiles (the automation I assume you refer to) as a technology that will eliminate the need for server engineers who understood the core technologies (memory, CPU, HDDs, NICs, PCIe, power & cooling) of the physical server platform? You won’t find it on my blog and I don’t recall seeing it on yours (

      We both understood that the use of a UCS Service Profiles was to more quickly and efficiently deploy/re-deploy purposefully and properly configured physical servers. Service Profiles were NEVER positioned as an easy button that eliminated the need for an astute server engineer with core knowledge of how to properly build, configure, troubleshoot, etc. a physical server.

      I believe if you read the post in the proper context, there’s no irony. The article’s point was “Network admins [are] an endangered species” and I flatly disagree with that point. Automation is not an easy button that renders network admins useless or endangered.

      That I’m aware of, VMware has never claimed that server virtualization or the automated deployment of VMs renders server admins useless or endangered. I also assume that VMware doesn’t believe network virtualization, centralized control planes or the automated deployment of network services renders network admins useless or endangered. Please correct me if my assumptions are wrong.

      I hope the irony here won’t be that VMware’s position on server virtualization’s impact on server admins is different than that of network virtualization’s affect on network admins.

      • Bradley777

        Hey Sean. What I’m referring to is the supply side disruption with automation. Not the consumer side — the content of your post (which I agree with). I could have been more clear about that.
        Put another way, when it’s time to take market share with automation (servers), you (and I) brought out the “Easy Button”, and we LOL’d at the incumbents throwing back the “Not so Easy” FUD at us. Now the time has come to defend market share from automation (network), and I’m seeing a “Not So Easy” button here on your blog. That is all bro. You know I love ya man :)


        • Anon

          As someone who spends quite a lot of time working with UCSM and vSphere, as well as being a CCIE, I laugh when I see all the FUD coming in all directions re SDN.

          The only thing I can say for sure is that, as always, the engineers that will prosper in the coming years are those that can adapt (to whatever) and the one’s that won’t are those that can’t adapt.

          I also roll my eyes at the ‘CLI is so nineties’ nonsense. I love a well-designed GUI (UCSM/vSphere client), and I love a bit of CLI. Each has their place. I still need my ‘esxcli’ commands in VMware and even PowerCLI for a bit of automation. And I absolutely hate the vSphere web-client :-)

  • Colin Lynch

    Nice simple pictorial analogy Sean, am having many similar conversations about Overlays requiring fast low latency reliable Underlays. Will certainly “pinch” your picture for future discussions :-)