With the advent of software defined networking (SDN) and the move to incorporate automation, orchestration, and extensive programmability into modern network design, it could easily be argued that programming is a must-have skill. Many networking professionals are asking themselves if it’s time to pick up Python, Ruby or some other language to create programs in the network. But is it a necessity?
Interfaces In Your Faces
The move toward using API interfaces is one of the more striking aspects of SDN that has been picked up quickly. Instead of forcing information to be input via CLI or information to be collected from the network via scraping the same CLI, APIs have unlocked more power than we ever imagined. RESTful APIs have giving nascent programmers the ability to query devices and push configurations without the need to learn cumbersome syntax. The ability to grab this information and feed it to a network management system and analytics platform has extended the capabilites of the systems that support these architectures.
The syntaxes that power these new APIs aren’t the copyrighted CLIs that networking professionals spend their waking hours memorizing in excruciating detail. JUNOS and Cisco’s “standard” CLI are as much relics of the past as CatOS. At least, that’s the refrain that comes from both sides of the discussion. The traditional networking professionals hold tight to the access methods they have experience with and can tune like a fine instrument. More progressive networkers argue that standardizing around programming languages is the way to go. Why learn a propriety access method when Python can do it for you?
Who is right here? Is there a middle ground? Is the issue really about programming? Is the prattle from programming proponents posturing about potential pitfalls in the perfect positioning of professional progress? Or are anti-programmers arguing against attacks, aghast at an area absent archetypical architecture?
Who You Gonna Call?
One clue in this discussion comes from the world of the smartphone. The very first devices that could be called “smartphones” were really very dumb. They were computing devices with strict user interfaces designed to mimic phone functions. Only when the device potential was recognized did phone manufacturers start to realize that things other than address books and phone dialers be created. Even the initial plans for application development weren’t straightforward. It took time for smartphone developers to understand how to create smartphone apps.
Today, it’s difficult to imagine using a phone without social media, augmented reality, and other important applications. But do you need to be a programmer to use a phone with all these functions? There is a huge market for smartphone apps and a ton of courses that can teach someone how to write apps in very little time. People can create simple apps in their spare time or dedicate themselves to make something truly spectacular. However, users of these phones don’t need to have any specific programming knowledge. Operators can just use their devices and install applications as needed without the requirement to learn Swift or Java or Objective C.
That doesn’t mean that programming isn’t important to the mobile device community. It does mean that programming isn’t a requirement for all mobile device users. Programming is something that can be used to extend the device and provide additional functionality. But no one in an AT&T or Verizon store is going to give an average user a programming test before they sell them the phone.
This, to me, is the argument for network programmability in a nutshell. Network operators aren’t going to learn programming. They don’t need to. Programmers can create software that gathers information and provides interfaces to make configuration changes. But the rank-and-file administrator isn’t going to need to pull out a Java manual to do their job. Instead, they can leverage the experience and intelligence of people that do know how to program in order to extend their network functionality.
Tom’s Take
It seems like this should be a fairly open-and-shut case, but there is a bit of debate yet left to have on the subject. I’m going to be moderating a discussion between Truman Boyes of Bloomberg and Vijay Gill of Salesforce around this topic on April 25th. Will they agree that networking professionals don’t need to be programmers? Will we find a middle ground? Or is there some aspect to this discussion that will surprise us all? I’ll make sure to keep you updated!
The Networking Nerd 
Don’t be a jack of all trades, and an ace at none.
These big wigs sounding off on SDN are forgetting something important: we are human. A (good) network engineer who decides to learn programming (on a level that is impacting to SDN) will find that his networking skills will fade away. As the Marines say, “Whatever you do in training, you’ll do in combat.” If you don’t train with networking daily, the skill WILL fade, and by the time you learn enough programming to create SDN things, it will have been a pointless effort if you can’t remember how OSPF, BGP, MPLS, Ethernet, IPsec, DSCP, TCP, etc. all work in detail.
There are, of course, exceptions. These are the people who have given up their social life and choose a night in the lab instead of with girls.
Better it is for the network engineer to collaborate with the programmer to create SDN. Back in the day, we used to call this “teamwork”. This new era is moving away from teamwork, into this “I can do anything!” selfish dogma, needs to stop. Put down the Python book, and go ask for help. It will make the task at hand get accomplished faster (including SDN), and encourage healthy relationships at the same time — something everyone could benefit from these days.
You were not created to study your entire life for something that changes on a daily basis. Don’t study a few years, just to produce a silly ping script that you can ask your programming friend to make in less than 5 minutes. If you think it’s fun, great — have at it. Just keep in mind that nobody is going to remember your ping script, just like they don’t remember IPX. If you’re not an expert, team up with the expert. THIS is how we get to SDN.
This reply is a joke right? You can’t actually be serious.
Care to provide more constructive feedback? Just because his views didn’t line up with yours doesn’t mean he’s necessarily wrong. You just responded with some snark reply without addressing any of his points. I am inclined to side with Ben on this matter.
I’d rather be an ace on one subject that jack of all trades. Ivan Pepelnjack seems to agree as well http://blog.ipspace.net/2016/12/python-for-networking-engineers.html so I wouldn’t say it’s as black and white as people make it out to be. … ‘I would always prefer to get the job done by a specialist who has programming experience comparable to my networking experience.’
My day job is writing code that deals with hundreds of thousands of network devices (routers/fws/switches) that still require screen scraping and config mangling. Many of these production devices are on ancient platforms.
I’m not some architect in a fantasy land where I dream up of some green field turn key automation solution and dump work on operations to implement and support. Most of these architects I’ve seen talking about these SDN designs can’t code themselves, but they are excellent network engineers/architects. Code I write still hast to cater to the lowest common denominator and these aren’t devices with fancy APIs, standard command line, code base and or network architecture.
SDN may change the way we work with networks, and that may necessitate the acquisition of different skill sets, but as a network engineer, my primary qualification is first and foremost, understanding how those packets flow and how to efficiently move these flows, not around operating someone’s niche platform(s).
Understanding basic fundamentals of programming is becoming increasingly important. Not only for networking professionals, but across all disciplines. Querying and massaging data sets from multiple sources will lead to incredible insights, discovery and optimization of the world around us. There is also a certain amount of art and creativity that goes into developing the algorithms to identify and eventually visually represent meaningful or interesting information from all this merging of 1’s and 0’s.
Those who are experts in the craft and have programming skills will do very in their careers.
So, I was going to write a blog response (and I may still) but I’m fully immersed in Formula One’s opening weekend in Melbourne, so this comment will have to do. As a network engineer who programs, or a programmer who networks, or maybe just a jackass, I don’t think the conversation is as black and white as people make it out to be. You can do both things well, and not to the exclusion of a social life; you can do more than one thing at once, and be good at all of them. Just because you learn BGP very well, you don’t automatically forget OSPF or forget spanning tree (even if we wish we could). The only reason we combine layers one, two, and three, and four into a coherent profession is because we just decided that made sense at some point in the past.
I do believe there will be different levels of skills, and blends of skills, just as we have now. There will be plenty of entry and mid-level engineers running software to allow them to configure the network, just as they do today. The software may change from the GUIs the manufacturers build (though I don’t believe as much as people think), but the job tasks will be similar, an evolution instead of a revolution. You’ll also have the handful of true experts, one or two in a company, most working as consultants of one flavor or another, or in hyper-scale data centers, and these will be the folks diving into the weeds. Will they be expert programmers themselves? Some will, some won’t. Some will partner with programming teams to accomplish the grandiose, while others will work with other engineers to make utilitarian and highly specialized-to-an-environment applications around automation and orchestration.
At the end of the day it’s about knowledge, experience, wisdom… all of the things we value in both software and network engineers today. Is there a place for someone who can configure routing protocols or network fabrics using memorized commands, often without understanding the deeper protocols? Certainly. Will there be a place for engineers who can write software to automate and/or orchestrate the processes within a network? Absolutely. But as is the case today, the most valuable skill set will be having the deeper understanding of how to solve business problems, how to do so with the best tools possible, and understanding the reasons why.
I agree with the comments above. There is a definite need for collaboration. We have to work as a team to continue the progression of the Datacenter Network Fabric and Automation. The reality is that major vendors are actively working against open automation and collaboration. There is also another issue that is not being mentioned. The insecurity of the legacy engineers actively blocking any technology that would unseat the vendor they have followed for the last 20 years. They are closed minded and afraid of being replaced. We will always need Layer 3 experts and they will have a place/purpose but they need to evolve as well.
Pingback: Reaction: The Future is... - 'net work
Pingback: Links de Segunda #03 | Homelaber Brasil
Pingback: Reaction: The Future is... - rule 11 reader
As a network engineer who programs, or a programmer who networks, or maybe just a jackass, I don’t think the conversation is as black and white as people make it out to be. We have to work as a team to continue the progression of the Datacenter Network Fabric and Automation.
A (good) network engineer who decides to learn programming (on a level that is impacting to SDN) will find that his networking skills will fade away. We have to work as a team to continue the progression of the Datacenter Network Fabric and Automation.
We have to work as a team to continue the progression of the Datacenter Network Fabric and Automation.
SDN may change the way we work with networks, and that may necessitate the acquisition of different skill sets, but as a network engineer, my primary qualification is first and foremost, understanding how those packets flow and how to efficiently move these flows, not around operating someone’s niche platform(s).
As a network engineer who programs, or a programmer who networks, or maybe just a jackass, I don’t think the conversation is as black and white as people make it out to be.
SDN may change the way we work with networks, and that may necessitate the acquisition of different skill sets, but as a network engineer, my primary qualification is first and foremost, understanding how those packets flow and how to efficiently move these flows, not around operating someone’s niche platform(s).
SDN may change the way we work with networks, and that may necessitate the acquisition of different skill sets, but as a network engineer, my primary qualification is first and foremost, understanding how those packets flow and how to efficiently move these flows, not around operating someone’s niche platform(s). We have to work as a team to continue the progression of the Datacenter Network Fabric and Automation.
We have to work as a team to continue the progression of the Datacenter Network Fabric and Automation.
SDN may change the way we work with networks, and that may necessitate the acquisition of different skill sets, but as a network engineer, my primary qualification is first and foremost, understanding how those packets flow and how to efficiently move these flows, not around operating someone’s niche platform(s).
Pingback: What is Software Defined Network (SDN)? - Grandmetric
Pingback: Czym jest Software Defined Network (SDN)? - Grandmetric