Summary

AutoCon0, hosted by the Network Automation Forum (NAF), is a conference focused on figuring out ways to increase network automation adoption across the industry. There were presentations, panels, and vendor booths present at the conference to help drive the conversation. I wish I could highlight each presenter/panelist, as I was able to take something away from each one, but then this post would turn into a book! Instead, I’ll highlight the conference by breaking it down into two sections: Tech and People + Processes. These two sections make the most sense, as they are the two driving factors to network automation adoption. Lastly, I’ll provide my take on some of the topics discussed at the conference.

Conference Highlights

Tech

I’ll start with the tech, as that can be the most exciting for engineers. There were many sponsors supporting and attending the conference, including Itential, Kentik, Nokia, Arista, NetBox Labs, and IP Fabric to name a few. For a full list of sponsors, check out the NAF AutoCon0 event page here. In short, there was no shortage of cool automation products to check out at the conference. The vendor booths provided a lot of insight into their products, but interestingly, I was more surprised at the number of conversations I overheard of people talking about solving problems, not just selling products. That helped reinforce why I was at the conference – to figure out why network automation hasn’t been fully adopted yet.

I can’t cover every product I checked out, but I wanted to highlight three of the sponsors: Arista, Nokia, and Ops Mill.

Arista

My good friend Julio Perez was there representing Arista. You may know Julio from his amazing blog posts on networking and automation. If you haven’t checked them out before, I highly recommend giving them a read. I sat down with Julio and discussed some of the automation use cases we’ve seen with clients and shared ideas. He also gave me a demo of Arista AVD. AVD, or Arista Validated Designs, allows you to deploy Arista’s validated network design topologies using Ansible, based on best practices from their design and deployment guides. AVD will take care of configuring each device in the network fabric in an accurate and consistent manner. For more information, check out the arista.avd collection on Ansible galaxy and AVD on GitHub. As a bonus, he also showed off the Arista Network Test Automation (ANTA) framework. As someone that enjoys and evangelizes network testing, I’m planning to dive into ANTA in the future.

Nokia

Nokia had two products that I wanted to highlight – containerlab and SR Linux GPT. If you’ve read my previous blogs or checked out my YouTube channel, you’ll know I’m a big fan of containerlab. Containerlab allows you to build a virtual, containerized lab of network devices and Linux containers. Even better, no servers required! You can spin up containerlab right on your laptop! The only thing you’re responsible for are the images, but vendors like Arista and Nokia make it stupid simple to get started for free! For more information on containerlab, check out their docs. If there’s anything you take away from this post, please check out containerlab. It can be an invaluable learning aid! SR Linux GPT is another neat project Nokia talked about at the conference. SR Linux GPT allows you to ask questions to your network device(s) in a natural language. For example, asking your device how many interfaces are currently up, or asking how to configure a specific feature on the device. The best part about it is that you can install it for free using apt or yum right on your Nokia device. For example, when logged into your Nokia device, install with the following command:

sudo apt install -y srlgpt

I’ll end by saying that the SR Linux GPT project is a proof of concept and still experimental, so don’t think AI is going to take your job overnight!

Ops Mill

Ops Mill is the new kid on the block and founded by Damien Garros and Raphael Maunier. Damien was at the conference and spoke about his new product. From what I gathered, Ops Mill is meant to solve the issue of what I’m calling “automation drift”. Automation drift occurs when engineers build automation around a specific data model, whether that be a database or simply a YAML file. In many cases, this data model is called the source of truth (SoT). The issue is that you’re giving up something with each approach – database vs YAML file. A database can be difficult to maintain, especially when a change to the underlying schema is required. You have to plan and implement a migration to the new schema, which can be tricky. Once the new schema is in place, all automation built around that schema must be updated to account for the changes. On the flip side, a YAML file is flexible and can easily be tracked with version control. However, there’s a major lack of structure when it comes to YAML. Key-value pairs can be added without tricky migrations, but at any moment, the structure of the data model can change. Additionally, the data type of values (i.e. string, integer, etc.) can not be validated without an additional data parsing and validation layer. Ops Mill is looking to solve this challenge by providing a database that is heavily integrated with git and can be tracked with your data. The overall goal is to have any database changes tracked via git with the rest of your changes. This will provide more context and avoid having to adjust automation to your data model, as the model will be version-controlled with the rest of your changes. If you’d like to learn more about Ops Mill, check out their website. I believe there will be more to come in the new year.

I hope this gave you a small taste of the different products and tech that you could find at the conference. I wish I could talk about more sponsors, but this post would get to be wayyy too long. I do recommend going to each of the sponsor’s websites and get familiar with their tooling so that you’re aware of what’s out on the market. Let’s move on to the more difficult topic – People + Processes.

People + Processes

People and processes was the topic of many presentations and panels. Kaon Thana, who works at the New York Times, had a presentation about his journey to adopting network automation and how it’s been a multi-year process. That may not be surprising, but he mentioned that they are nowhere near a 100% automated network and logging into devices to access the CLI is still required. I’m not surprised, as I don’t think a 100% automated network is a sensible goal. Engineers will need to be in the loop to help make crucial decisions and manage the automation workflows. That statement may bother some people that believe AI will take over all network operations, but let’s be honest, many network engineers barely trust an Ansible playbook? Hence, the purpose of AutoCon0 – to increase trust and adoption of network automation.

Beyond the process, there was a major focus on the people side of the equation. Two major themes were brought up by presenters and panelists as it relates to people – trust and consumption of automation. Having trust in the automation was probably the most repeated topic. Many network engineers have trouble trusting automation, whether it’s pushing configuration or providing observability. Pushing configuration is scary for engineers, even without automation, so pushing configuration at scale with automation can be daunting. Luckily, if automation is created correctly with a system-based approach, automated testing is included to validate the configuration and operational state of the network pre and post-changes.

Automation should be deployed as a system versus a one-off script or playbook. An automation system should be able to translate a declared design into rendered configuration and provide the necessary validation to ensure the network is running as expected, according to the design. Jeremy Schulman had a great presentation about this exact approach – design-driven network assurance. His AutoCon0 presentation compliments his recent NANOG presentation, where he went through the concepts that make up a design-driven automation system that he’s deployed at the MLB. If you haven’t had the pleasure of watching a presentation by Jeremy, I recommend (at a minimum) watching his NANOG presentation before the AutoCon0 presentation recordings are published. That will help provide background to his AutoCon0 presentation.

Consumption is another obstacle to network automation. It’s easy writing your first “hello world” script to connect to a device and run a command, but how do you pass that script on to the next engineer? Most automation scripts are written in silos and never leave the engineer’s laptop. Pushing it to a remote git repository store, such as GitHub or GitLab, is a step in the right direction. However, that still doesn’t solve the issue of someone else using it. One of the discussions around consumption revolved around how non-programming engineers can consume the tools automation engineers build. Some of the presenters showed off tools that were full-blown web apps, and others were CLI tools. I think it’s important to recognize that the consumption of automation sources back to how engineers in your org expect tooling to be presented. Web apps are popular nowadays, but CLI apps may be familiar for engineers and provide more granular control with the use of command-line options and flags. Another way to consume automation is through the use of a text-based user interface (TUI). I’ve built a TUI app that helps network engineers learn network automation – net-textorial.

My Take

In an effort of figuring out why network automation hasn’t been adopted fully, I came away from the conference with the following takeaways:

• Automation, or any large process change for that matter, requires buy-in.
  • That includes your team, management, and the people that write the checks. Adopting automation doesn’t just cost money for tooling and training – it costs time. Regardless of the monetary investment, time is the one thing that will be pressed and become an issue if there isn’t buy-in.
• Start with the low-hanging fruit and build on the easy wins.
  • This may seem obvious, but get the quick wins! Once you see results, regardless of scale, you’ll be motivated and believe that automation can take your team to the next level. P.S. Easy wins don’t have to include pushing configuration at scale. It can simply be backing up configuration files to a git repository or collecting operational state at scale using “show” commands. My recommendation is to start with read-only operations – it reduces risk and honestly might teach you a couple things about your network’s running state.
• Automation is a journey, not a race.
  • I’ve always referred to learning automation as a journey and, after listening to the presentations and panels, it was apparent that others do as well. In a world where new shiny tooling and products are created/presented daily, it can be hard to stay focused on the end goal. As Dan Kelcher mentioned in his presentation, you must know your destination! Of course, tooling will change over time, so it’s important to understand how each piece of the puzzle fits together and to stick with your automation strategy.

Bonus Take

Since you made it this far, I figure I can provide one more take… Another topic addressed during the conference was AI. Some presentations discussed incorporating AI into operations (AIOps). The idea is to have AI detect failures before they occur and, potentially, fix issues proactively. This introduces the topic of closed-loop automation, which is the continuous monitoring, measuring, and optimization of the network. Closed-loop automation is the ideal end-state for many network operators, but is it plausible? Do we trust AI to make changes and optimize the network automatically based on collected measurements and analysis? In my opinion, I think AI fully managing the network is a pie in the sky idea. It’s not to say the data being collected or analyzed is inaccurate – it’s more about the decision making. Sometimes reasoning for a network change or current network state is based on information that can not be inferred from collected network data or external data sources.

I believe AI can provide amazing insights into your network, but deciding whether to act on the insights should be left to the network engineers. I would love to hear your take on AI and how it can best be used in the network!

Wrapping Up

I hope this post helped you understand the goal of AutoCon0 and what the Network Automation Forum is all about – to figure out why network automation hasn’t been fully adopted, yet. If you have any questions or would like to chat about network automation, please feel free to hit me up on Twitter/X (@devnetdan) or LinkedIn!