This post was originally published in the Human Infrastructure newsletter. If you’d like to get it for free, sign up here.
The AutoCon conference took place November 13th and 14th in Denver, CO. Developed and launched by Chris Grundemann and Scott Robohn, the conference, along with the umbrella organization Network Automation Forum, aims to build a community of practitioners to help advance the state of the art in network automation. Packet Pushers was a media partner of the event, and Ethan Banks and I attended. We were joined by just over 300 other attendees and speakers, along with a handful of vendor sponsors. Here are three impressions I took away from the conference.
1. There’s a hunger for network automation
If infosec has a reputation as the Department of No, I think networking has a reputation as the Department of Slow. For about as long as I’ve been covering the industry (more than 20 years), a common complaint from other IT teams and the business side of the house is that networking is the laggard when it comes to standing up new applications and services. The rise of virtual machines and then public cloud, each of which accelerated app deployment, has only cemented that reputation. Compute can be summoned with a few clicks, but networking (particularly on prem) often requires tickets and emails and questions and wait times that can stretch from hours to days.
Networking teams know they need to automate to keep pace. They want to automate! It hasn’t happened for reasons too extensive for this short post. What AutoCon clearly demonstrated is that what’s not lacking is desire.
2. Adoption roadblocks are cultural, technical, and budgetary
While the desire is there, the roadblocks are significant. Cultural issues include engineers who don’t want to abandon the CLI for reasons including significant professional and financial investment in the CLI, a dislike of programming, and a legitimate concern that executives see the word “automation” and start salivating about staff reductions.
Technical issues include the ever-moving hockey pucks of languages, tools, and platforms (Python, Ansible, Terraform, Netbox, Nautobot, Nornir, Git, and who knows what comes next), a lack of conformity around data models, a reasonable unwillingness to try to build and maintain automation tools in-house, and gnarly brownfields em-barnacled with rules and configs that, like Jenga blocks, may or may not topple the whole network if you mess with them.
On the budgetary front, many companies seem unwilling to invest the time and money to train their networking staff or allow for the risk-taking required with new automation projects that might result in errors that impact the business. More can be said about these roadblocks, but I’ll move on.
3. Lots of networking orgs want vendor tools!
There’s a definite DIY vibe to a lot of network automation projects. Many are built around open-source tools and projects. That’s great for individuals with an interest in this work and teams at forward-thinking companies that will invest in and support home-grown efforts. But that’s not most companies.
Most companies want vendor-supported tools that will actually help them be more efficient, reduce human error, and increase the velocity at which the network team can support new apps and services.
The problem is that you can’t just buy a “network automation” product. Network automation requires coordination across almost innumerable devices and systems, each of which performs a critical function that has to be reliably triggered in the right order with the right information. There are APIs to link up and data models to rationalize. There are Sources Of Truth to be identified and maintained. There are issues around visibility, monitoring, management, and resource consumption, not to mention policy and compliance.
There are significant opportunities for vendors for here. What’s more, network automation is a heavy lift that no one vendor can manage. There’s lots of market share to go around.
However, vendors aren’t known for working well together. This means networking organizations have to very careful and deliberate about the vendors they choose, and it can take significant time and effort to parse real capabilities from press release buzzwords. In many cases companies may be stuck with deeply entrenched “partners” that have little incentive to sing Kumbaya with competitors or other players. But the need for real partners is there, and network engineers must make their demands known.
I was encouraged by the energy, ideas, and enthusiasm swirling around AutoCon0. There are a lot of benefits to a tightly-focused conference. I hope this community continues to grow. I also hope to see AutoCon1 on the calendar for next year.
