Is it planning… or just plain engineering?
Over at the ECI blog, Jonathan Homa has a nice article about the importance of network planning–
Jonathan describes why this is so–traffic is constantly increasing, and the choice of tools we have to support the traffic loads of today and tomorrow can be classified in two ways: slim and none (as I remember a weather forecaster saying when I “wore a younger man’s shoes”). The problem, however, is not just tools. The network is increasingly seen as a commodity, “pure bandwidth that should be replaceable like memory,” made up of entirely interchangeable parts and pieces, primarily driven by the cost to move a bit across a given distance.
This situation is driving several different reactions in the network engineering world, none of which are really healthy. There is a sense of resignation among people who work on networks. If commodities are driven by price, then the entire life of a network operator or engineer is driven by speed, and speed alone. All that matters is how you can build ever larger networks with ever fewer people–so long as you get the bandwidth you need, nothing else matters.
This is compounded by a simple reality–network world has driven itself into the corner of focusing on the appliance–the entire network is appliances running customized software, with little thought about the entire system. Regardless of whether this is because of the way we educate engineers through our college programs and our certifications, this is the reality on the ground level of network engineering. When your skill set is primarily built around configuring and managing appliances, and the world is increasingly making those appliances into commodities, you find yourself in a rather depressing place.
Further, there is a belief that there is no more real innovation to be had–the end of the road is nigh, and things are going to look pretty much like they look right now for the rest of … well, forever.
I want you, as a network engineer, operator, or whatever you call yourself, to look these beliefs in the eye and call them what they are: nonsense on stilts.
The real situation is this: the current “networking industry,” such as it is, has backed itself into a corner. The emphasis on planning Jonathan brings out is valid, but it is just the tip of the proverbial iceberg. There is a hint in this direction in Jonathan’s article in the list of suggestions (or requirements). Thinking across layers, thinking about failure, continuous optimization… these are all… system level thinking, To put this another way, a railway boxcar might be a commodity, but the railroad system is not. The individual over-the-road truck might be a commodity, and the individual road might not be all that remarkable, but the road system is definitely not a commodity.
The sooner we start thinking outside the appliance as network engineers or operators (or whatever you call yourself), the sooner we will start adding value to the business. This means thinking about algorithms, protocols, and systems–all that “theory stuff” we typically decry as being less than usefl–rather than how to configure x on device y. This means thinking about security across the network, rather than as how you configure a firewall. This means thinking about the tradeoffs with implementing security, including what systemic risk looks like, and when the risks are acceptable when trying to accomplish as specific goal, rather than thinking about how to route traffic through a firewall.
If demand is growing, why is the networking world such a depressing place right now? Why do I see lots of people saying things like “there will be no network engineers in enterprises in five years?” Rather than blaming the world, maybe we should start looking at how we are trying to solve the problems in front of us.
Hi Russ,
Few of my thoughts :
1. The problem space is largely created my big players in Network Industry. To most Network Engineers it seems to be an easy pick in where they think if they master few top products, they should be able to get a job or stay relevant in job. For example ACI, NSX etc. Most engineers I know hardly understand how things work in the background. While in my view creating abstractions and hiding complexity could potentially benefit a Client (If they just focus on brighter side of things) but most Network Engineer don’t go beyond learning fancy GUI interfaces as well.
This is a very different situation few 5 years back where most Network Engineers use to admire and keen learning details of Protocols and Architectures.
But if you look closely, you would probably agree that there aren’t many learning tools available to them either when it comes to learn new protocols and architectures other than reading through dry RFCs.
For example something like VxLAN. Most of new generation Engineers don’t know architectural guidelines around how to size VxLAN domains and how to handle Broadcast or Multicast. Most traditional players in training industry don’t have training modules focussed on new technologies as deep dive sessions.
So I guess new generation of engineers pick the easy things to survive which is learn products and stick with it as they know vendors will push that shiny stuff as much as they can from ROI perspective and maintain if not gain the current market share which will keep these guys relevant and in job.
My 2 Cents…
HTH…
Evil CCIE