operationalizing network automation & enabling team-oriented development with torero

If you’re a network engineer and you’re writing automations, chances are you’re tired of the operational bull****. I’m tired of seeing team after team run into the same challenges—it’s one thing to build a cool script that works on my laptop. But sharing those automations with others can slow everything down—you’re either troubleshooting by hand every time (not scalable) or building your own vertical solutions on top of your automations (not efficient + difficult).

We built torero to solve the operational challenges around network automation and allow network automation engineers to stay focused on what you actually want to be doing: writing automations, not managing how others consume them. To tell the truth, I have my own selfish stake in this. Too many times, I’ve built something awesome that I want to share with someone else, and it’s at the point of sharing where it falls flat.

I was excited to announce the launch of torero at AutoCon 1 in Amsterdam a few weeks ago. But I was even more excited by the positive feedback. Challenges operationalizing automation were a big focus at AutoCon 0 last year, which is part of why we decided to build torero in the first place, and I’m looking forward to seeing what the network automation community will do with the free tool going forward.

For a quick overview of torero you can watch my presentation below:

On top of the baked-in difficulty you see when you try to share scripts (libraries, dependencies, etc.), there’s another large-scale challenge to sharing network automations: teams don’t use a single tool to automate networks.

It’s the age-old adage: we’re using the right tool for the right job. We’ve got tools to do just about everything in network automation now, but, while we can push config, create configs based on templates, whatever else, we’re missing the final piece — how do I get this automation off of my laptop? How can others on my team, the NOC, security teams, etc. use it? And how do I do that efficiently when we’re using such a variety of automation tooling?

Network engineers shouldn’t be system admins. It’s not only difficult, it’s impractical. A network automation engineer might be able to manage and maintain a vertical solution for others to consume one automation script. Or two, or five. But what if you’ve built twenty automations? A hundred? Network engineers can’t be asked to build entire operational platforms that support logging, security, etc. if we want to scale automation efficiently.

torero takes the responsibility off of network automation engineers by streamlining automation execution. I’ve seen network teams really dive into automation headfirst in the last few years. Network engineers are good at writing automations for point-specific jobs, and they’re only getting better. The bottleneck for delivering network services rapidly at scale isn’t writing automations — it’s exposing automations to the teams who need them, without introducing extra risk or taking up a significant portion of network engineers’ workshare.

This is why I’m so excited about what torero means for network automation. It’s about filling a gap that network engineers needed to fill, allowing teams to do more with less effort and expand the reach of the awesome automations they’re already building.

If you want to hear more about how torero is solving network automation problems, I also sat down with Packet Pushers’ Ethan Banks to discuss the tool post-launch. Watch below:

torero is what I’m calling an automation gateway. It’s designed to provide a universal execution layer for network automations — whether it’s Python scripts, Ansible Playbooks, or OpenTofu plans — so we can operationalize automation in a streamlined, efficient way.

With an automation gateway, when you want to ship off an automation to another network engineer or another team, you can just do it. They won’t need to know it’s built in Python or Ansible or whatever you chose, they won’t need to have a deep understanding, they can just use the run command in torero and receive the outcome they need. That’s the power of torero — it’s a simple tool, but one I expect will have transformative impact for teams who are committing to network automation.

The most important piece of this automation gateway model in my view is the fact that it allows network engineers complete freedom of choice for automation tooling. I know how much muscle memory and familiarity can help with productivity. I’ll probably never stop using Vim, and I’ll be honest, I even use it to write my emails. If you have to learn new tools and/or new languages to be able to build shareable, scalable automations, it can slow teams down — especially if you’re using a variety of different tools for different automation jobs.

The point of an automation gateway, the point of torero, is to provide a seamless solution that fits right into how teams work today. It’s automating things engineers would otherwise do manually, creating a universal execution experience for automations built with all sorts of tools that can integrate with a pipeline or your northbound system of choice for ease of use.

It’s about enabling teams to take that next step, to operationalize the awesome automations you’re building in the easiest, fastest way possible.

For a deep dive into how torero came to be and an in-depth discussion on features and architecture, listen to this episode of Packet Pushers’ Network Automation Nerds podcast — you’ll hear a more detailed explanation of how torero works and how I expect teams to use it.

I’ll end with this: it’s clear that the network automation community is evolving at a rapid pace. At both AutoCon events I heard incredible stories of innovation and transformation as teams continue to innovate and accelerate. Our goal with torero is to give the community an easier, faster path, allowing you to keep moving forward without getting lost in managing and maintaining solutions just so others can leverage the automations you build.

If you have any feedback, questions, or ideas for torero, you can join the NAF Slack space and drop in our #tools-torero channel. And if you’re interested in joining the conversation on the future of network automation, be sure to check out AutoCon 2 coming up in November this year. I look forward to seeing some presentations where torero plays a role!