The Engineering-Operations Disconnect in Network Automation (& How to Fix It)

The relationship between network automation engineers and network operators sometimes feels like a breakup “on good terms.”

We’re totally cool. Chill, even. Just as long as we don’t speak to each other or see each other ever again unless absolutely necessary.

It doesn’t have to be this way. We’re all on the same team. But we’re stuck with systems and incentives that make working together unnecessarily complicated. Teams who build automations use Python or frameworks like Ansible and OpenTofu to create scripts, which require environments and dependencies to be executed. Often, operations teams aren’t trained in building and maintaining execution environments — and a reskill effort isn’t scalable. So the responsibility for providing an operational layer falls on the automation developers, who then have to spend a lot of time away from building and updating automations.

To truly deliver services to automation consumers at scale, this has to change.

How can automation developers efficiently deliver services to consumers without losing time managing the operational side? How can consumers, well, consume those automations, without spending time learning Python or Ansible or requiring direct hands-on input from the automation builders?

In short, how do we achieve operational scale?

Teams all over are working on improving their operational solutions for automation. It doesn’t do any good to build a cool script if nobody consumes it. Developers end up maintaining environments and dependencies, managing access, and troubleshooting when operations teams and developers need to consume automations.

And while this might be doable when you’ve written one or two scripts, what about dozens? Hundreds? What happens when some people on your team write Python, some write Ansible, and then you add OpenTofu Plans to automate cloud activities on top of that?

Script sprawl is a reality for network teams everywhere. To streamline how automations are delivered and consumed — to truly operationalize automation for scale — it’s a problem that needs to be solved.

That’s why we created Itential’s Automation Service: to bridge the gap, heal the network relationship tension, and enable organizations to operationalize automation at scale.

Itential’s Automation Service is the apology text we’ve been waiting for.

By combining automation gateway capabilities with the ability to publish automation services to Itential Cloud, our automation service streamlines the automation experience for both sides — builders and consumers. I’ll explain those two pieces in a moment, but the ultimate result is this: builders can build how they want, with the tools with which they’re most familiar, and operators can consume automated services quickly, easily, and reliably, without the need for any special skills. Plus, you get enterprise-grade features around role-based access control, execution auditing, and input validation to maintain standards while delivering automation across the organization.

Finally we’ll be able to just be friends again (only this time it actually works).

Now let’s get into how this whole thing works.

What’s an Automation Gateway?

At the core of our new automation service is what’s called an automation gateway — a tool that’s built to standardize how automations are executed and turned into services, no matter what language or framework was used to build the automation.

The gateway enables streamlined execution of Python scripts, Ansible Playbooks, and OpenTofu Plans by auto-generating a virtual environment right before execution, based on the requirements file associated with a given automation script that the automation author checks into a Git repo. Previously, network automation developers would need to hand-build a virtual environment based on that requirements file to enable someone else to run it. With Itential, those manual steps are handled for you.

There’s no more “please send me the output” or “you forgot about this dependency.” The gateway is designed to skip manual steps while simultaneously increasing consistency, ensuring things just work smoothly. When automation developers build services in this way, you free yourself from a never-ending pile of operational tasks and scale your capabilities to meet the needs of the business.

Why Do I Need to Connect My Automations to Itential Cloud?

Even if you’re able to wrap a service around an automation so a consumer doesn’t need to be familiar with the underlying code, there’s still a gap to get to the point where they can run it like a cloud service. Maybe most of your operators are comfortable with calling a service from the CLI. But is everyone? And is that the best way to ensure processes and standards are followed consistently?

The other half of Itential’s Automation Service is the ability to publish and expose automated services as products in a catalog, represented by a GUI and accessed through Itential Cloud. For operators, this means a simple list of services, with descriptions and required inputs provided. These services can be ordered and run instantly, like cloud services, and as long as you’ve built your automation in accordance with standards and requirements and implemented the appropriate access controls, it’s safe to run with no direct oversight.

That’s where we get into the ‘scale’ portion of what I’m talking about. If you can achieve this catalog model for delivering and consuming network automations, then your organization can run an automation thousands or hundreds of thousands of times per day — without increasing workload for the network automation/NetDevOps team. The network scales to support the growing needs of the business, without adding hours, headcount, or complexity.

By bridging the builder-consumer divide, Itential’s Automation Service doesn’t just resolve today’s network automation challenges — it creates a foundation for transforming the way network automation delivers value to the organization and streamlines the way different sides of the house can work together.

Automation teams can focus on innovation rather than operationalizing their solutions, unlocking new levels of efficiency.

Imagine a world where network automation is as seamless and user-friendly as the public cloud. The future of automation isn’t just about streamlining processes; it’s about transforming the way we work together. And hey, who knows? Maybe automation developers and network operators will even be swapping holiday cards again.

Watch this demo to see our new service in action!