The network won’t fit in your head anymore
Triggered by a discussion with a customer yesterday, it occurred to me (again?) that network engineers are creatures of habit and control. We have strong beliefs of how networks should be architected, designed and build. We have done so for long times and understand it well. We have tweaked our methods, our tools, our configuration templates. We understand our networks inside out. We have a very clear mental view of how they behave and how packets get forwarded, how they should be forwarded. It’s comfort, it’s habit, we feel (mostly) in control of the network because we have a clear model in our head.
I don’t believe this is a network engineering trait per se. Software engineers want to understand algorithms inside out, they want to understand the data modeling, types structures and relationships.
Uncomfortable
Many of us know the feeling. Something new comes around and it’s hard to put your head around it. It challenges the status quo, it changes how we do things, it changes what we (think we) know. When we are giving responsibility of something new, there is a desire to understand “it” inside out, as a mechanism to be able to control “it”.
Over the last year I’ve had the opportunity to hear about lots of new and exciting products in the network and virtualization world. The one clear takeaway from all of these meetings has been that the vendors are putting a lot of their focus into ensuring their product can be automated. While I agree that any new product on the market needs to have a robust interface, I’m also sort of shocked at the way many vendors are approaching this. Before I go further, let me clarify two points. First, when I say ‘interface’ I’m purposefully being generic. An interface can be a user interface, it could be a REST interface, a Python interface, etc. Basically, its any means in which I, or something else, can interact with the product. Secondly, I’ll be the first person to tell you that any new product I look at should have a usable REST API interface. Why do I want REST? Simple, because I know that’s something that most automation tools or orchestrators can consume. 


