Automation vs. Control Plane

I listened to the latest packetpushers episodes this morning (Show 198 - Kirk Byers on Network Automation with Python & Ansible - Packet Pushers Podcast) and started thinking about the opportunity cost of learning the things discussed in that episode. Essentially, two hours spent on learning how to manage the network better is two hours not spent on getting stronger in how to manipulate the control plane. If networking remains a largely distributed system like it is now, the control plane will obviously remain important and you can't automate what you don't know. If you don't know what to put in those configuration templates of yours, you're not in good shape. On the other hand, if your idea of managing a network is just typing and pasting things manually into the CLI, that's not exactly great either.

You need both of these skillsets, but the question is to what degree. Are they different roles? The routing nerd who knows the protocols and their behaviour in different circumstances, and the network automation person. Is the same person expected to be an expert in both?

Thoughts?

Find more posts tagged with

Comments

networker050184

Whether they are different roles depends on the size of the company usually. We have a team of guys in our engineering group that does nothing but scripts and tools that we need. It's a full time job in itself. If it was a smaller company we'd likely need to do these things ourselves. The automation guys were all network engineers prior to moving over to the dev side so they certainly know what they are doing though.

I've been trying to learn some scripting here and there when I can. Slow going for sure, but it is certainly a nice skill to have.

NightShade03

networker050184 wrote: »

Whether they are different roles depends on the size of the company usually. We have a team of guys in our engineering group that does nothing but scripts and tools that we need. It's a full time job in itself. If it was a smaller company we'd likely need to do these things ourselves. The automation guys were all network engineers prior to moving over to the dev side so they certainly know what they are doing though.

I've been trying to learn some scripting here and there when I can. Slow going for sure, but it is certainly a nice skill to have.

+1

Many of the network engineers today are starting to see a shift in how environments/networks are run and managed. The traditional config switches and map out the network isn't slow starting to fade away with the increase in consumption of things like virtualization and SDN. While we aren't there yet with SDN, some bleeding edge companies (and start ups) are seeing the value in SDN and being able to build your entire network through scripting vs old school configs. Automation and orchestration both play a big role here. The good news though is that things like ansible, chef, and puppet were all designed for server automation so by the time we include things like networking/switches many of the platforms will be in a more mature state.

Traditional network configs aren't going anywhere just yet either though so I would say both skills are good to have. The biggest benefit I see to developing scripting skills is if you are looking to switch jobs. Having both skills, or at least a working knowledge of them, certainly makes you more marketable. Obviously the challenge here is that those who are true network engineers probably didn't need to know/understand a ton of scripting which makes learning scripting a semi-daunting task.

fredrikjj

networker050184 wrote: »

We have a team of guys in our engineering group that does nothing but scripts and tools that we need. It's a full time job in itself. If it was a smaller company we'd likely need to do these things ourselves. The automation guys were all network engineers prior to moving over to the dev side so they certainly know what they are doing though.

What's the ratio of script people to "classic" network people?

networker050184

We have three automation guys to around fifteen engineers.

reaper81

I have been considering what to do. I came to the conclusion that CCDE fits my role better for what I am doing now. I am more of a designer/architect/subject matter expert but I still do some hands on as well.

I don't believe everything will run on magic overlays. Overlays are fine, MPLS is a form of overlay, as is GRE. Centralized control planes aren't really new either. Sure, we will see changes but to what extent is unclear yet. I don't see traditional networking going away anytime soon, and even with overlays we are still depending on properly designed physical network etc.

So I'll come back in a year or so and reconsider my choice. For the time being, although scripting surely could help me in some way, it's not part of my job.

lrb

Our team supports a lot of Juniper kit which we manage through Puppet. I certainly don't have a software engineering background but wrote most of the scripts and configured the Puppet master without too many hassles. If you have some scripting background, I don't think it's too hard to knock something up in Puppet.

In IT we naturally must upskill constantly anyway so just treat learning orchestration tools as another technology that you would if you were studying for a technology you weren't familiar for the CCIE