What’s Stopping the Adoption of Network Automation?
Summary
Is there a gap between the potential of network automation and widespread industry implementation? Phil Gervasi explores how the adoption challenges of network automation are multifaceted and aren’t all technical in nature.
AutoCon 0 was a pivotal event in the network engineering world. Most attendees were involved with networking in some meaningful way, and everyone I spoke with was interested in increasing the adoption of network automation. It was a fantastic event to attend.
With the recent NetDevOps Days London and New York and now AutoCon, it’s fantastic to see a completely focused event for the networking community to gather and discuss methods, tools, workflows, and lessons learned of practical network automation. Specifically, AutoCon 0 was a laser-focused event, and the desire to embrace network automation was palpable among attendees. However, despite recent technical advancements and growing excitement, a recurring theme at the conference was the noticeable gap between the potential of network automation and its actual implementation in the industry.
A network automation reality check
AutoCon 0 brought together practitioners new to network automation and experts implementing complex workflows. However, according to a show of hands in one of the sessions, most attendees were not implementing network automation practices in any meaningful way.
But why? We’ve been talking about network automation for years, so why isn’t the networking industry farther along with mass adoption?
Over the last decade, innovation in network automation has involved fine-tuning automation workflows, creating device templates to make configurations more consistent and easier to automate, and creating integrations with network-adjacent services like DNS, IPAM, CRMs, etc. Network vendors have also been busy making their devices more accessible via NETCONF and REST APIs. So, people are trying, and vendors are responding. Nevertheless, adoption has yet to take off like we expected.
What’s the network automation holdup?
The stumbling blocks for the adoption of network automation are multifaceted and aren’t all technical in nature.
1. Complexity of network systems
One of the most significant barriers is the inherent complexity of today’s networks. Many organizations still operate legacy systems that are not readily compatible with modern automation methods and solutions.
We also have the complexity of modern networks, even if the systems are cutting-edge. A modern network includes campus devices from various vendors, abstractions and overlays, network adjacent devices, cloud and container networking, and so on. Automating an infrastructure when that infrastructure is both complex and only partially owned by the operator is a stumbling block to getting started.
And as much as we’d like to deny it, every network is still a snowflake. Even if we reach the point where networks are 80% the same organization by organization, there will always be that unique use-case, one-off problem, and bespoke design. The reality is that no one automation technique or method will work for everyone.
2. Skill gap
Next, network automation requires unique skills that blend traditional networking knowledge with programming ability. In theory, learning a new skill wouldn’t be a stumbling block if network operators working in the trenches had unlimited time, resources, and a reliable and stable network that didn’t need attention.
I repeatedly heard that many network engineers got into networking because they hated their 100-level programming classes in college. Networking was a way to stay in the tech field without being a programmer. Therefore, many network engineers have a deep-seated aversion to programming and a reluctance to develop that skill. This has given rise to “codeless” automation platforms such as Itential, Gluware, and Pliant and the developing partnerships between observability and automation platforms.
3. Cultural change
Change is hard, especially in large, established organizations. There’s often a cultural resistance to adopting new technologies, particularly when it involves fundamental changes to how networks are managed. The truth is most of us have built our networks, including the internet itself, mostly without network automation. That means justifying the cost and pain of organizational change to leadership is a hard sell. Many network pros are heavily invested in (and tied to) their unique network implementation, and it could be that they feel it’s their unique responsibility to keep it going with their embedded personal knowledge.
4. Trust issues
We should exercise healthy caution with anything that directly impacts application delivery. However, some engineers have trust issues with handing over configuration changes to a script. I wonder if that’s really warranted, considering we have imperfect people changing the config on the CLI directly. Mistakes certainly happen all the time with legacy network operations. In fact, more than once, I’ve taken a network down or at least impacted network activity by implementing an incorrect command or some other human error.
When network automation is implemented cautiously and as part of an operational workflow, rather than increasing errors, we’ll see _fewer _errors and more stability. It’s easier to correct errors if you have automation in place. We have version control, a central place to fix typos, etc. Nevertheless, we must still overcome trust issues among engineers and automation processes.
5. Financial constraints
The initial investment in automating networks can be substantial. Consider the cost of upgrading skills, possibly hiring new engineers, the loss of production time to implement new workflows, and the licensing cost of new tools and databases. For many companies, the ROI is not immediate, which will lead some decision-makers to forgo implementing network automation altogether and focus on activities with quicker returns.
I’d argue this is short-sighted, but it’s still a prevalent stumbling block mentioned several times throughout AutoCon 0.
Lessons learned in network automation
The lessons were plain to me. I heard them repeatedly in various presentations – even the session on AI and LLMs. Surprisingly, almost all of them relate to culture and people and very little to technology itself.
Embrace incremental change
All the experts who spoke at the conference emphasized the importance of taking incremental steps towards automation. Automating small, routine tasks can build confidence and demonstrate value, opening the door to bigger, more impactful network automation activities.
Invest in training
Bridging the skill gap is crucial. The industry needs to invest in training programs that equip network professionals with the necessary skills for automation. Relying only on individuals to independently acquire the skills they need to automate their networks means change will continue to go at a crawl. Organizations need to take professional development more seriously.
Culture shift
Organizations also need to cultivate a culture open to change and innovation. This involves top-down directives and encouraging a mindset change at all levels, from management to front-line engineers. Our networks have changed dramatically over the last few years, so it doesn’t make sense to operate them the same way we always have.
Showcase the long-term benefits
Getting around short-sighted leadership is an uphill battle. The value in network automation isn’t purely short-term, so that means explaining the diverse value of network automation will depend on an organization’s culture, goals, and leadership.
It can be challenging to communicate the long-term benefits of network automation beyond immediate cost savings, especially when there may not be immediate cost savings. Network automation generally provides little to no short-term gains, so we need to showcase the long-term efficiency, reliability, and scalability improvements.
AutoCon 0 was a reminder that while the journey towards widespread network automation may be slower than expected, it’s still very much underway. Yes, there are challenges and stumbling blocks for leadership and engineers. However, there is a growing excitement and community around network automation that, hopefully, will soon lead to significant changes in how we operate our networks.
About a year ago, Scott Robohn and Chris Grundemann first had the idea for the Network Automation Forum and AutoCon 0. Now that the community has rallied around advancing the adoption of network automation, I’m looking forward to the amazing success stories shared at AutoCon 1.
