Observations from NAF AutoCon0: The Need to Differentiate Automation & Orchestration

I’m sure most of you have seen some of the recent hype behind Network Automation Forum’s first ever one of a kind network automation event, AutoCon0. It’s new, fresh, and something our industry has quite frankly been lacking for a while. But, as with all new things, you might be wondering — is it just hype? Or is there real potential for impact?

After attending AutoCon0 in Denver, I can 100% confirm that the hype is justified.

The event far exceeded my expectations going in. There were over 300 networking professionals in attendance, and it felt like pretty much everyone shared one goal: learning and sharing new ideas around how to accelerate the adoption of network automation across our industry. I’ve never seen such a large, focused gathering of what we sometimes call “network unicorns” in my 25 years working in the networking industry.

Network unicorns are individuals with dual skillsets, familiar with network engineering and proficient enough with programming tools like Python to build automations. These unicorns are rare, but there’s a growing community that I saw on display at AutoCon0. These are the individuals who are going to make automation progress happen, and AutoCon0 has helped spark a renewed interest in understanding the what, why, and how of network automation.

Perhaps the most important concept that people took away from AutoCon0 is the idea that we need to define automation and orchestration as two distinct ideas, related but separate concepts. This was a common theme across several presentations and matched up with the conversations I had in Denver.

Automation vs. Orchestration: Defining the Difference

Historically, the difference between automation and orchestration has been muddled and grey. That hasn’t been helped by us vendors, either — everyone in the industry has been a bit too happy to use the terms interchangeably. But AutoCon0 proved that highlighting the differences and solidifying our definitions provides clarity to network engineers and leaders alike, helping people understand what they want to achieve, what challenges they face, and what solutions exist (vendor, open source, or both) to support their efforts. Here’s how we defined the two ideas over the course of the event:

Automation refers to task-focused automations, built with tools like Python and Ansible or with vendor and device-specific tooling. Automation happens at the domain layer, and each automation domain has its own requirements and standards — firewall configurations have different requirements to a data center or an SD-WAN controller, for example.

Orchestration is about stitching all of these automations together, integrating across different domains as a kind of horizontal layer above the individual automation domains. It’s about putting processes together in accordance with business needs and automating them end-to-end. It also means steps like data gathering, validation, and documentation can be integrated with the end-to-end orchestrated process.

TLDR; Network Automation vs. Orchestration

Why is this distinction important? Judging by what I learned at the event, it’s rooted in the challenges network teams face today as they continue to implement network automation. Understanding the difference gives people the clarity they need to take the next step forward with network automation.

For network engineers (or soon to be network automation engineers), understanding the difference helps you focus on your role without the need to also write a bunch of integration code to build the orchestration layer. Or, if you’re a network architect who’s focused on driving efficiency end-to-end, you can make plans with an orchestration mindset while allowing individuals to keep building their automations.

Knowing what automation is, knowing what orchestration is, and understanding the difference between the two gives more clarity to your automation journey and helps you determine which tools or solutions you need to solve the challenges you’re facing.

The Role of Vendors in Advancing Network Automation & Orchestration

AutoCon0 was first and foremost a gathering for the network automation community. It was a place for people to come together and share strategies, experiences, and thoughts around how to approach automation initiatives so that our industry can kickstart automation adoption. As someone who works at a vendor in the automation and orchestration space, though, I think it also gave us a really clear call from the community about what they need from us as vendors.

I’ll start with the message that I heard repeated again and again: all vendors in the space need to share publicly available APIs in standard formats to facilitate integration. Whether that’s DIY integration with custom code, or leveraging vendor solutions for orchestration, it’s critical that we make that baseline first step.

But going beyond that, we have a key role to play that starts with meeting network automation engineers where they are – and that only happens by listening to the community and what they’re demanding. The future of automation and orchestration is a multi-technology, multi-domain world—that’s why orchestration is an important topic to begin with — and we need to support every aspect of that, even if it means we need to work together more.

Above all, engineers are tired of being “trapped” (direct quote!) by vendors and vendor offerings. What I heard over and over from the participants at AutoCon0 is that they’re prioritizing solutions that don’t lock them into a single vendor’s devices, building scripts with a single programming language, or any other restrictive requirements. Whether you sell automation technology, an orchestration solution, or a key networking service like an inventory or IPAM system, you should prioritize making sure your offerings can become part of the open vision for automation — which means published APIs, integration partnerships, integrating with popular tools and languages , etc. That way, you can enable people at every stage of the automation journey, from writing their first scripts to orchestrating end-to-end processes across a global network.

It’s about becoming part of the movement, part of the community that’s committed to evolving our industry and adopting orchestration to get the most out of automation initiatives. AutoCon0 was an incredible event, and a rare chance to see so many network automation unicorns in one place — I can’t wait to see how things have progressed by the time the next one rolls around.

If you want to dive deeper into the key takeaways from the event, check out this new episode of the Telemetry Now podcast, where Peter Sprygada joins to discuss AutoCon0 and automation adoption in the network industry as a whole.