>_network automation should not be a herculean effort
It’s hard to fathom one’s journey into and around network automation. Over the last 15 plus years, it has been filled with moments of elation followed by periods of despair regarding the state of automating networks and network devices. CLI screen scraping, Netconf, Restconf, JSON-RPC, OpenConfig, you name it, it has been done by individuals to varying degrees of success. Let’s not forget RANCID, Net::Telnet and expect/pexpect giving way to tools and frameworks such as Ansible, netmiko, nornir and so many others.
One of the common denominators across all these efforts has been the herculean efforts of individuals, typically in their “spare” time to bring to fruition a cornucopia of scripts, playbooks, tools, and frameworks in efforts to keep pace with the dizzying pace of new builds and change requests.
>_let’s eliminate the automation bull****
The sheer number of tools and technologies that comprise the network automation ecosystem can be absolutely paralyzing for teams and organizations to get started. The prevailing advice for a long time has been, to quote Nike, “Just Do It.” While that advice is as applicable today as it has ever been, it quickly brings to light a significant number of secondary challenges around bringing these efforts together in such a way that teams can easily coalesce around network automation regardless of what tools and technologies have been used.
Today, we are very excited to announce the general availability of torero and the torero.dev community.
>_what is torero?
Abstractly described as an automation gateway, torero is uniquely built and provided to the broader network automation community to allow network engineers to begin the transition from localized automation development to team oriented development. It focuses on creating and delivering a uniform experience for operationalizing disparate approaches to achieving network automation.
Whether its Ansible playbooks, OpenTofu plans, or internally developed Python scripts and tools, torero is purposely built to seamlessly and frictionlessly position itself to launch and execute automation services without burdening teams that need to maintain multiple vertically built and costly operational stacks.
>_what is an automation gateway?
With the plethora of automation tools in use running against infrastructure, trying to keep operational control can be a daunting challenge. Turning to an automation gateway can greatly bring sanity to an otherwise chaotic world of scripts, playbooks, tools, and frameworks. By focusing on a consistent, repeatable execution layer, automation gateways give operational teams the ability to maintain uniform control regardless of the language, framework, or application used to push changes to infrastructure.
team dev >_ local dev with torero
While we have put forth a significant effort to build and realize the torero application, it is foremost designed to cultivate a community of liked-minded individuals. In that light, torero.dev provides a centralized meeting point for exploring and driving the direction of torero.
So today, I encourage you to download torero and try it out in your environment. It’s ability to quickly and easily integrate into network automation development and operational stacks should be seamless. Moreso, torero’s unique capability to dynamically build the execution environment at runtime removes many of the challenges associated with transitioning automations from locally developed to being shared by the entire team. No more headaches trying to keep development and product infrastructures in-sync with dependencies and library versions. Quickly switch from one version of a dependency to another with ease to test and validate new releases of core libraries and frameworks.
Most importantly, we want to hear from you. The good, the bad…. where torero got it right and where torero got it wrong. Visit torero.dev and sign up to stay informed about new releases, features, and developments around torero and/or reach out to us on X @torero_dev and LinkedIn.
Or if you’re at AutoCon 1, I’ll be there at the Itential booth so you can stop by and provide your realtime feedback or get a demo.
We hope you will find using it as easy and as enjoyable as we had building it.
Happy Automating!
Tags: OpenTofu Python Red Hat Ansible
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.
