I posted a Tweet the other day which gained a lot of attention in the networking community:
As SDN gains more traction, people start fearing for their jobs. Some jobs will decrease in demand and some will disappear entirely. However, we can’t stop progress just to keep those jobs hanging around. In the Twitter thread I made what could be seen as an elitist comment:
If you are replaceable by a script or controller, you were never a Network Engineer to begin with.
This was not meant to insult anyone, but rather be a wake-up call. If the only value you provide to the business is that you deploy templates someone else created, configure VLANs on a trunk, or can trace a flapping MAC in the network, you need to reskill and find ways of providing more value. This is not about Junior vs Senior. It’s about solving business problems.
Now, please don’t believe the “All Network Engineers must become programmers” mantra. That doesn’t mean that some people won’t be working in those roles. It doesn’t mean that those skills aren’t useful. They are. Very much so. However, how do you automate something you don’t know how to do manually? Pro tip: You don’t. You still need to know the fundamentals.
So, in a SDN world, what will Network Engineers do? Well, how about:
- Design networks
- Create configuration standards
- Troubleshoot networks
- Connect sites together over the WAN
- Connect on-premises to cloud
- Integrate network design and security design
- Provide connectivity to external networks
- Design and implement cloud networks
- Design and implement wireless networks
- Connect IT and OT environments
There will still be a lot to do. And the good news! It will likely be more entertaining than just banging commands on the CLI.
People tend to underestimate the network. “I just need the plumbing for my apps”. Which is true. Until you start adding constraints. Until you start adding physics. Until you start adding users. Until your network needs to scale. Until you find a bug. Until you find out the network is flat and open to attacks. The TL;DR, the network is not going away, and neither is your job, if you provide value to the business.
Any type of automated solution requires a lot more thought to be put into the design before going into implementation. This includes things like:
- Categorizing your sites
- Coming up with name standards
- Coming up with standard configurations
- Validating the design
Failure to do so will just mean that you’ve just automated your failures.
SDN may be scary, but it didn’t eat your hamster.
Daniel, you always give us a lot to think about, and this blog is no different. I do not hide the fact that I am not exactly an SDN enthusiast… but it was your tweet and this post that made me really think about what is it that unsettles me about SDNs.
The way I see it, and this is my personal opinion, despite SDN standing for Software Defined Networking (or sometimes Software Driven Networking, a term I like better), the “Networking” aspect has gradually become a minor, second-class part of the whole paradigm, not a cornerstone of it anymore. The true meat in SDNs nowadays is the automation of tasks and orchestration of different moving components so that they move in unison. But networking? That comes into picture only because all those moving components and automated tasks expect to have network connectivity. “Expect” is the keyword here – SDNs do not come with new networking technologies; with a few exceptions (that only prove the rule, such as ACI), SDNs merely reuse whatever existing networking technology is there, and do not bring substantial innovations in this field. MPLS, Segment Routing, TRILL, FabricPath, LISP, VXLAN, EVPN… here’s but a couple of moderately recent technologies with some of them being heavily used in SDNs, yet none of them invented as a part of SDNs. To paraphrase E. W. Dijkstra, “SDNs are no more about networking than astronomy is about telescopes”. It is a wishful thinking to position SDNs as “the future of networking”. No – SDNs are more about overall future of network-assisted computing, but networking is treated just as a tool by SDNs, not as a focus of targeted improvement and evolution. This also brings along the explosive increase of the overall complexity of the SDN solutions that obscures and obfuscates the actual networking aspects. While RFC 1925 is primarily meant as a joke, there is a healthy core to those twelve networking truths, and Truth 5 describes SDNs in a staggeringly prophetic way: “It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.”
I am not scared at SDNs, nor am I opposed to them per se. What I am at odds with, however, is the gap between how they are marketed (a new generation of networking) and what they really are (frameworks to automatize and orchestrate disparate elements in comprehensive solutions). You wrote yourself that networking is not going away. Indeed – but for me as a hardcore networker, the added complexity of SDNs I am supposed to master is a detractor from what is my own bread and butter: Getting datagrams from one end host to another across an internetwork – and this is surely not about delaying progress to keep my old-school-style job. If the future expects me to become a specialist in multiple areas including automation and programming (and once again, I am a software engineer by upbringing so I am not afraid of it), so be it, but in the same way you asked for candor, I am asking for it too: Let us stop calling those added areas that constitute SDN’s center of gravity, or relating to them, as “networking”, for they are not.
I agree, network analysts/engineers/specialists will not need to become “programmers” but they will need to know how to code. There is a difference between a professional programmer and a coder. The first one is a profession or job, the second is what someone is willing to do to get the job done. The first one is about a body of processes and procedures and organization, the second is about being practical.
There’s a lot to be gained from learning coding but like you said, that’s a profession in itself. Knowing a bit of Python, Git, Ansible, APIs will probably cover most use cases and then use the professionals for the real advanced stuff. Thanks for commenting!