An automation-first approach enables network predictability

An automation-first approach is one of the most effective ways for an organization to embrace network automation within its network management processes and bring more predictability to networks.

In networking, an automation-first approach centers network planning on automation capabilities. Several vendors have touted this strategy, but automation-first approaches permeate through to actual network automation techniques that IT teams and organizations use. To put automation first, both vendors and IT organizations have a role to play, according to Jason Edelman, author and co-founder of Network to Code, a network automation consulting firm based in New York. Both vendors and organizations must prioritize workflows and understand where network automation fits within them.

In the book Network Programmability and Automation: Skills for the Next-Generation Network Engineer by Edelman, Scott S. Lowe and Matt Oswalt, the authors tackle the critical skills network engineers need as the industry increasingly turns toward automation.

Editor's note: The following interview was edited for length and clarity.

How have you seen network automation change the way IT teams function?

Click here to learn more
about this book.

Jason Edelman: In the past 18 to 24 months, there's been way more openness to learn the tools and technologies that often fall under the realm of network automation, so I think that's a shift in the right direction.

There's a lot more interest from folks just getting started. There's also a significant difference with how businesses embrace and approach it because those two things are always good to separate. The personal growth of an individual -- they could read articles, read books, pass exams -- but there's also the practicality of using those skills within an enterprise or within a customer environment.

More automation-first conversations are happening on the network side -- maybe not enough that we need in the industry, but there's definitely been a drastic shift with the customers we deal with day to day.

What could the industry do more of to take an automation-first approach?

Jason Edelman

Edelman: I look at it from both sides: What could be done within an IT organization, and what could be done in the vendor community? Oftentimes, IT environments look to vendors for guidance. I think it's fundamentally flawed because IT departments go to these large manufacturers and ask for guidance and help, and [the vendors] proactively give it, and the help is often product-centric. It's 'You want to get better operations or better automation? You need this new product or widget.' It sells [customers] on the false idea that a single product or tool is going to help on the network automation journey.

Network automation survives around workflows. Once anything is purchased, how is it consumed within the IT organization? There's a huge gap in understanding workflows. Even in the automation space with folks that get it, people focus a lot on tools and how tools can enable network automation. But then there's the gap of selecting these tools and how we really use them. It starts being very network administrator- or network operator-driven.

I believe every network -- small, medium or large -- should have some level of automation.

The important piece is doing network automation to enable other teams. This network team might enable the security team, or they might enable the help desk to perform a basic action on the network. It's understanding the best way to deliver the network automation solution. I think there's a gap of how things should be exposed to the greater organization.

More training is always better. New certifications are launched; more courses are online, which are good, but there's a general myth that, once somebody takes a week-long course or two weeks of training, they should be able to automate. There's a general misunderstanding that network automation skills could be gained in short order.

People have to reflect and say, if they're a career network engineer or even a career director of networking, that was likely years in the making. Some primitive [network automation] skills can be learned within six months to a year, but to really make an impact and a dent, it's going to take time. Crafting the right growth plans internally would be valuable.

How does a network automation approach change network engineers' existing network management processes?

Edelman: It should drastically change it. A network engineer today spends most of their time in the network command-line interface -- in the CLI. For network engineers making hands-on changes every day, every week in the [CLI], putting a few commands in a Notepad file, nothing is predictable. It's like normalized chaos in each person's brain versus having a more methodical way to manage it.

In our world of network automation, we want to minimize the use of [CLIs] and then ideally get to the point in time where we understand what's driving that change and go further north, so it should be able to dynamically get closer to the business. I would say, fundamentally, network engineers are going to shift away from using a CLI to using network automation tooling.

I believe every network -- small, medium or large -- should have some level of automation. Not because of size or scale, but for predictability and having a deterministic outcome in any environment. That way, things are proven and properly version-controlled, so people know the state of the network through a well-defined process.

I think network automation skills should be pervasive. The level of depth is going to vary greatly, but we have a few different categories and basic skills. If we look at things like Linux, Git, YAML, JSON and Jinja templating -- we would say, arguably, everyone should have a base understanding of those, and the deeper they are into the automation hands-on, then they would get deeper into a given area.