Don’t Hate the Player, Hate the Tools
The other day I came across an article, “Industry execs: Network admins an endangered species,” and I have to say, the headline did its job. I had to read more.
Executives from HP and Juniper, in particular, contend that network virtualization, and specifically Software-Defined Networking (SDN), will bring new levels of automation to networks, which in turn will lower operational costs because network administrators will no longer be needed. Specifically, their argument is that administrative or “people” expense is much higher than equipment costs, so automating will eliminate significant expense.
That’s one way to look at it I suppose. However, I would suggest that automation presents new opportunities for the networking team.
It is true that achieving significant OPEX savings is a key part of our discussion with customers when we talk about Embrane’s network services automation solutions that are being implemented today in enterprise data centers. However, we don’t talk about it in the context of, “how many heads can I cut?” Instead, our conversations center around how our customers can best use the people they have, and what tools are needed to enable the right level of talent to perform the right tasks.
The reason we’re having about network agility and automation is because the network hasn’t evolved like compute and storage technologies have. As a result, enterprise network teams have not had tools to enable them to deliver self-service, automated network infrastructure. The truth is current network infrastructure is being rendered inefficient and increasingly harder to troubleshoot. So, network operations folks have no choice but to spend time on manual, low-impact tasks. The result: increased OPEX.
Who is best suited to evolve these networks? The people who are so intimately familiar with them – network engineers. When we talk with customers and prospects, we show them how our solutions provide the tools for their skilled engineers and architects to eliminate the mundane network administration and transform networks so they maintain the reliability we enjoy today, while adding the significant agility and flexibility now required of the network — which was the catalyst for the innovation that is SDN in the first place.
Why am I so confident that giving the networking team the tools to automate certain functions will lead to significant OPEX savings without requiring significant layoffs? History tells me so.
Look no further than the adoption of virtualization. Did the increased efficiency and agility cause a decrease in the number of system administrators? No. It allowed them to provide more value to their organizations as their focus shifted to areas that helped drive the business. The technology absolutely lowered OPEX and increased efficiency, but those savings were not necessarily achieved through dramatic headcount savings.
Embrane’s CTO and Co-founder, Marco Di Benedetto, put it best: “Their [network architects] brain can decrease OPEX when they have the right tools in their hands; the wrong tools are going to cause havoc.”
This is not to say networking professionals don’t need to evolve their skills. But I see this as an opportunity for them to make themselves more valuable, not less. As an example, smart CCIEs will grow their skills to include some basic knowledge of scripting languages, such as Python, so they can now support both traditional and software-defined networks.
So, while I fully agree with the argument that SDN is helping the industry automate certain functions and evolve networks to become much more agile, I don’t expect to see teams of networking people out on the streets. What I do expect is that we will see savvy network engineers look at the move to virtualize networks and implement SDN as an attractive career move. In fact, I’d love to hear from engineers and architects who see this as I do, and understand how they are going after the opportunity to leave rote tasks they’ve been bogged down with behind and play a role in driving the companies they work for forward.
