An automation-first approach to network predictability

An automation-first approach is one of the most effective ways for enterprises to adopt network automation in their network management processes and bring more predictability to the network.

In networking, an automation-first approach focuses network planning on automation capabilities. Multiple vendors are now touting this strategy, and the automation-first approach has trickled down to the actual network automation technologies used by IT teams and enterprises. Jason Edelman, co-founder and author of network automation consultancy Network to Code, believes that in order to put automation first, both vendors and IT organizations have a role to play. Both vendors and enterprises must prioritize workflows and understand where network automation fits within them.

In the book Network Programmability and Automation: Essential Skills for the Next Generation of Network Engineers, co-authored by Edelman, Scott S. Lowe, and Matt Oswalt, the three authors explore the key skills that network engineers will need as the networking industry increasingly moves toward automation.

[[332309]]

How do you see network automation changing the way IT teams operate?

Jason Edelman: Over the last 18 to 24 months, there has been a growing willingness to learn tools and techniques in the network automation space, so I think it's moving in the right direction.

Those who are just starting out are very interested in network automation. At the same time, there is a big difference in how enterprises embrace and deploy network automation, because these two things are best viewed separately. Network automation helps individuals grow (they can read articles, read books, pass exams), and it is also practical to use these skills within the enterprise or in a customer environment.

There are more automation-first conversations happening in the networking space - and perhaps as if these discussions weren’t enough, we’re seeing a significant shift among the customers we deal with every day.

What can the industry do to drive adoption of an automation-first approach?

Edelman: I look at it in two ways: What can IT do internally, and what can the vendor community do? Often, IT environments look to vendors for guidance. I think that's fundamentally problematic because IT departments look to these large manufacturers for guidance and help, and then the vendors proactively offer help, and their help is often product-centric. They'll say, "Do you want better operations or better automation? You need this new product or widget." Vendors will instill in customers the false idea that a single product or tool will help in the network automation process.

Network automation lives around workflow. After you buy anything, how do you use it in your IT organization? There is a huge gap in how people understand workflow. Even in the automation space, people are focusing on tools and how tools enable network automation. But there is a gap in selecting these tools and how we actually use them. It starts to be driven by the network administrator or network operator.

The important part is to do network automation to enable the support team to work. This network team may be able to support the security team or enable the help desk to perform basic operations on the network. There is a need to understand the best way to deliver network automation solutions. I think there is also a gap in how things are notified to the entire enterprise.

The more training, the better. New certifications are constantly coming out; there are more online courses, which is great, but there is a common misconception that when someone takes a one-week course or two-week training, they should be able to automate. There is a common misconception that network automation skills can be acquired in a short period of time.

People have to understand that if they are a career network engineer or even a career network director, it may take years to master network automation. People can usually learn some basic network automation skills in six months to a year, but to really make an impact, it will take longer. It will be valuable to have the right development plan in place internally.

How does network automation approach change the existing network management process of network engineers?

Edelman: It should change completely. Right now, network engineers spend most of their time in the CLI network command line interface. For network engineers, there is no predictability in making hands-on changes in the CLI every day and every week, and putting some commands in a notepad file. It's like the normal chaos in everyone's brain, and we need a more organized way to manage it.

In our world of network automation, we want to minimize the use of CLI and then ideally get to the point where we understand what is driving that change and further, it should be able to be dynamic close to the business. I would say that fundamentally, network engineers will transition from using CLI to using network automation tools.

I believe every network, small, medium, or large, should have some level of automation. Not because of scale, but because of predictability and having deterministic outcomes in any environment. That way things are validated and version controlled so people understand the state of the network through well-defined processes.

I think network automation skills should be ubiquitous, although the level of depth of that skill will vary greatly, but we have different categories and base skills. If we look at things like Linux, Git, YAML, JSON, and Jinja templates - we would say that everyone should have a basic understanding of those things, and the more they understand those, the deeper they will go into this area.