Dec 12, 2016
When discussing the value of an SD-WAN, many points enter the discussion. Cost comes up as SD-WANs are certainly cheaper. Delivering a better and more predictable user experience is another reason to adopt an SD-WAN, since users will certainly experience better application performance and, in turn, become more productive. But a third element that’s not talked about as much is the automation that SD-WANs bring to networking.
Network management is manually intensive and time consuming today. Things are done a box or location at a time, and network changes can take forever to implement. A recent study by ZK Research found that the average time to make a change to the network was over four months. Historically this hasn’t mattered that much, as the business and the network were somewhat decoupled. However, in today’s digital era where speed is everything, four months can be an eternity. Also, because of the importance of the network, most changes — even simple ones — are done by seasoned and senior network engineers. These expensive resources are spending the lion’s share of their time making repetitive changes to network devices via antiquated CLI interfaces, instead of working on strategic initiatives to move their organizations forward.
Automation changes the paradigm and makes the network dramatically more agile. However, in the past network engineers haven’t fully embraced automation for two primary reasons. It’s not because engineers fear the network becoming some kind of self-learning Skynet system that takes over the world and kills off all of humanity. The reasons are much more pragmatic.
Prior to being an analyst, I was a network engineer I feared automation. The main reason was that I didn’t trust turning the network over to a machine to make the changes for me. I was a pretty good CLI jockey back in the day, and through the use of scripts, custom code, and a lot of cut and paste, I could make changes at lightning speed. Of course, I made some errors along the way, which caused unnecessary downtime but I could fix that through more cutting and pasting, which might cause more problems. Seems cumbersome but hey, it’s way better than turning operations over to a machine!
The other reason — and few engineers will admit this — is that there’s a job security concern regarding automation. If a tool comes along and automates core tasks, what role will he or she play moving forward? Most people, even other people in IT, have no clue as to how a network operates and the stuff done at the command line level seems like some super network Jedi stuff that only the most highly skilled and technically trained and certified will understand.
The fact is, though, the world is changing and sticking with this mentality will eventually impact the organization. No matter how talented a network engineer is, there’s simply no way that the individual or team of people can work as quickly or efficiently as an automated system.
There’s lots of stuff being written about digital transformation today and how companies need to move with greater speed and agility. How is a business supposed to move fast if network changes take months to implement? Make no mistake, network managers need to embrace automation. Old school thinking is that there is a level of risk associated with automation but the reverse is true: by not automating network operations the risk increases of the business losing its competitive edge.
SD-WANs are grounded in automation and orchestrating network and application changes can be done in tight alignment with changing business requirements. SD-WAN rollouts can be done quickly and efficiently, automating configurations in alignment with business policy and intent. Dynamic tunnels, security controls and application optimization can be applied when the business needs it instead of when the CCIE has time to make the change.
There’s one more element that network professionals should consider. The world is changing and the skill set of every IT individual needs to change. Sticking with legacy processes that require manual configuration means the engineer isn’t learning the skills required to compete in the digital era. I’ll cover this topic and what skills network engineers need to acquire in a future post.