If you’re a network engineer, chances are you’re spending more and more of your time working on automation. Teams are building and executing scripts with a variety of DIY and open source tooling to accelerate automation activities.
However, there’s still a set of fundamental challenges with sharing and operationalizing network automation.
It’s great when something works on your own machine, but if you have to spend an hour troubleshooting when you share it with a teammate, you’re not saving time and you’re not saving effort. And isn’t that kind of the point?
torero came about because of this challenge. We saw and heard from the community that the operational layer is a significantly underserved area of automation, and we set out to build a tool that would do one specific thing: make it easier for NetDevOps teams to operationalize automation.
The idea is to take the activities you have to perform manually to share your automations, to build your own operational layer, and automate them. Crucially, torero is focused on augmenting and accelerating the way engineers are already building automations today. We’re not asking people to change up how they work, how they write scripts, anything — the goal is to fit torero into your toolchain as cleanly as possible so you can seamlessly operationalize network automations.
>_ torero q&a
The video below is an interview with Packet Pushers CEO Ethan Banks. He and I discuss the vision behind torero and how it fits into a network automation engineer’s operational stack as it exists today.
One of the most important things about torero is how easily it fits into the way network engineers are already working. Let’s dive into this a little more.
>_ how torero fits into your operational stack
If you’re writing code, you’re probably checking it into a repo to facilitate version control, visibility, redundancy, and collaboration with others on your team. I say probably, but what I mean is definitely. And this is true whether you’re writing your network automations using Python, Ansible, OpenTofu, or another language.
Of course, just because something’s in Git doesn’t mean your teammates can run it smoothly. If it’s a Python script, for example, you need the right libraries installed in your Python environment for the script to work. Whether it’s a teammate’s laptop or a virtual environment on a shared server, spinning up an environment with the right requirements will fall on somebody and take up time.
Each automation you build has associated requirements for its execution environment, stored in some variety of a requirements file that you’ll check into the repo. When you (or a teammate) go to spin up a virtual environment to run your script, you’ll refer to this requirements file.
torero replaces those manual steps. You can pass in a link to the repo you’re using to store a given script, and then pull in the requirements file(s), allowing torero to auto-generate an execution environment at runtime that meets all the requirements of your automation.
torero create repository example-scripts-repo --description "Simple repository for quick start" --url https://github.com/torerodev/example-scripts.git --reference main
Successfully created the repository Name: example-scripts-repo Description: Simple repository for quick start Url: https://github.com/torerodev/example-scripts.git Reference: main Tags: Private Key Name:
It doesn’t ask you to change how you use your repository or how you build your code — it just takes in what you have and helps you skip steps that are time consuming and prone to errors. This is crucial for sharing automations. There’s no more please send me the output from python –version, or pip list, or ansible –version, or netstat –nal, or anything like that. Instead, things just work.
In addition, torero has the capability to run in either local more or server mode. How we see this playing out is, you might start out using local mode just to build and test things on your own system. But when it comes time for the team to coalesce around network automation and really start to share assets more, the team can come together around one or more torero servers. An instance of torero running in server mode acts as what we call an automation gateway: a language-agnostic tool that provides a streamlined, centralized window into all of your complex production infrastructure. Then automations can be delivered as services to any users and teams who need to access them.
As we continue to develop torero and add new capabilities, we’re keeping this kind of operational ethos in mind. The goal is always going to be enhancing what you do today, fitting into your workflow — not dictating how you do things. It’s designed to fill a gap in your current toolchain, not to create a new one.
>_ why you’d use it
As teams continue to pursue automation and work to operationalize the automations they build, we’re seeing more and more teams running into similar challenges. It’s my belief that the automation gateway is that crucial missing link for teams to solve these challenges. NetDevOps teams are dealing with constantly increasing complexity and the need to automate across a variety of different domains, vendors, and device types with varying requirements and priorities.
The strength of torero is that the tool allows automation engineers to focus on automation and functionally ignore the operational layer. If you write automations with Python, and a team member is an Ansible expert, and then a member of the Cloud team is used to writing Terraform/OpenTofu plans, you can each keep building what you’re good at and share it with each other or anyone else who needs to access and run those automations.
We’re committed to making torero the easiest, fastest, most reliable way for teams to use one central gateway into their complex production infrastructure.
This will enable an operational model where everyone is maximizing their impact while minimizing wasted time, mistakes, troubleshooting, etc. Like I said at the top—the goal of automation is to save time and effort. If we zoom out to a business level, it’s also to drive efficiency across complex processes. torero is designed to enable all of that, without changing up how you’re working today.
Interested in trying torero yourself? Download and get started free today.
Peter Sprygada
Vice President, Product Management ‐ Itential
Peter Sprygada serves as the Vice President, Product Management at Itential after serving as the Chief Technology Officer at Pureport where he was responsible for their multi-cloud network as a service interconnect platform. Prior to Pureport, Sprygada was a Distinguished Engineer for Red Hat, where he played the role of Chief Architect for the Ansible Automation Platform. Sprygada also held senior technical and leadership positions at Arista and Cisco, as well as several networking startups.
