Advice on intent-based networking and Python automation

Most network engineers want their networks to run without any surprises, but that's often not the case. Traffic anomalies happen, complexity increases and the network gets blamed.

Over the past few years, data centers have grown exponentially with the network acting as the fabric that holds the myriad components together, according to Eric Chou, author of Mastering Python Networking, from Packt Publishing. Complexity has emerged as a byproduct of that growth, and network teams must manage underlays, virtualization, cloud, wireless and wired networks all at scale.

Network automation can make those responsibilities less daunting. Instead of relying on manual configuration tasks, network pros can implement automation scripts to save time and minimize the potential for human error. For Chou, this is where APIs and intent-based networking can shine, inserting validation, state awareness and automation into network management.

While APIs, intent-based networking and network automation aren't panaceas, they do provide network teams with more structure -- a predictable, defined network state. This predictability leads to more scalable operations, Chou said.

In his book, Chou provides readers with a blueprint of what he wished he had known about network automation and Python when he first started his automation journey, including scripts, APIs and the importance of starting small. Click here for a glimpse into APIs and intent-based networking from Chapter 3 of Chou's book.

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

How do you define intent-based networking?

Eric Chou

Eric Chou: I want to scale it back because the term has been overused by a lot of different companies and marketing departments, and they have their own definitions. Intent-based networking, for me, is to define a state that you want your network in and use all the tools available to enforce that state -- whether that's Python, Ansible, Puppet, Chef, whatnot.

Is it possible to create predictability in the network?

Chou: I think it's probably not possible, but it doesn't keep us from trying. The network, by definition, moves packets back and forth, so the network is always active, always fluid. And it's always dynamic, which is what's attractive about it, but what's scary about it as well. By the time you look at the network, it's already in a different state than the information [you originally received].

So, the network is fluid and unpredictable. But, within that scope, you're trying to decrease the unpredictability by putting guardrails around your network. Sometimes, you're looking at the network, and you're surprised by the amount of traffic or type of traffic that's passing through. By using automation with Python or Ansible, you at least put scope around your network so you're hopefully not surprised by it.

How do APIs work with that and build structure?

Click here to learn more
about this book.

Chou: APIs return structure output back. For some of the older network devices that don't have structured output, it makes it extremely difficult to have idempotency, meaning you could execute the same command over and over and you get the predictable outcome. You could kind of fake it with a human-centric management system, like the traditional iOS, but APIs take it to the next level and have that idempotency. The fact you can execute the same command, and it will always give you predictable output back and structure output back -- that really takes it into the modern world, where it allows computer-to-computer communication to happen.

Almost every single product, even the older products, now has some sort of API abstraction on top of it. By no means is that the last step, but it's the first step in getting your network ready to take your intent, or having structured output, just to be on par with other industries or fields, like system engineering or development. In a sense, networking was really lagging behind.

What is the main barrier preventing network pros from using and trusting APIs?

Chou: What was preventing was the supportability of the vendors. Vendors had their own way, and it'd been working for them -- namely Cisco -- so they had no incentive in changing. But then, five to 10 years ago, we had these disruptors -- Arista, open source operating systems, like VyOS -- all of them starting from day one because they didn't have the history or baggage. They were able to start from a model of structured output, where it has a centralized database or better state management. It brought out the better parts of Cisco to catch up to that. That was the first hurdle: the supportability from the vendor.

Now that the support is there and the capability from the hardware is there, now, the restriction becomes having the rest of the human capital catch up to that trend. Sometimes, the knowledge is there, but the hardware capabilities aren't. Sometimes, the hardware capability is there, but the soft part is not. It's not a black-and-white thing, of course -- sometimes, it's intertwined. In networking, we have these standards bodies, and we have these interoperability issues. So, I think, to a lesser extent, it's the lack of standards, the lack of interoperability, because everybody has their own agenda.

How can the industry promote API interoperability?

Chou: One thing we could do -- and what we're doing -- is educate more people about the benefits of APIs and let them make their own decisions about which way is better. Obviously, I'm biased -- I have my own opinion and preferences. But what I try to do, and I think a lot of other people try to do, is present a story and let people decide whether RPC [Remote Procedure Call] is the right way to go or Rust is the right way to go. Or whether you want to use XML or you want to use JSON.

I think we're on the right track, and we're getting people to form their own opinion and form consensus about what they want, at least at the baseline. We don't want to come to a world where everybody conforms to the lowest common denominator. But, at the same time, we have a baseline. We're all smart people that we could agree on a platform and, at the same time, allow innovation to happen by having these platforms that could signal the vendors' advantages and disadvantages.

Why is the chapter on APIs and intent-based networking so important?

Chou: If you look at the flow of the book, in the first two chapters, I covered the basics, which is necessary but kind of boring. This is the first chapter that presents actual scripts you could use tomorrow in your day job. Chapter 3 also covers different vendors. So, going back to what I was talking about with presenting the story. I am not making a judgment about Juniper using XML versus Cisco using YAML or JSON or whatnot. But it presents different vendor examples, so the readers are able to see what's similar and what's different about them. They're able to take it in and use it for their day job but, at the same time, observe the similarities and differences.

What was the biggest mistake you made when starting network automation, and what did you learn from it?

Chou: I think the biggest mistake -- that I later found out was false -- was that everything has to work right out the box, thinking that I have to reach a certain stage before I could make it useful. But the truth is you can start small and find small wins.

When I first started with Perl, it was very frustrating. It doesn't fit the way my mind was thinking, but I was hoping to make something useful out of it. I would start and stop, always thinking I have to reach this certain grand stage before Perl could help with my job.

But I changed that attitude when I touched Python and found out where I could start small and just tweak one or two little things that would help me and perhaps my co-worker as well. [Python] isn't just a language that's meant for web development or data science, network automation, DevOps and so on. In that regard, it's as if the language grows with you. I certainly didn't plan it that way, but it worked out that way.