Stop Trying to Grow Unicorns: Why Network Automation Needs Software Developers
Summarizing Antonio Balmaseda & Alberto Villegas Erce's software approach from AutoCon3
"We were basically trying to grow unicorns," admitted Antonio Balmaseda as he described their early automation attempts. "You can see a unicorn once, maybe twice in your lifetime... But you cannot grow a unicorn. You can grow a horse, you can grow a rhino, but a unicorn? Almost impossible."
The Spanish duo from Roche presented a refreshingly different take on network automation: stop trying to turn network engineers into developers, and start applying real software development principles to infrastructure challenges.
The Familiar Progression
Their journey echoed what many organizations experience. Starting in 2018-2019 with individual scripts and tribal knowledge, they attempted the classic "network engineers as code" approach—training network engineers in Python and Ansible through temporary assignments.
"This guy working in operations spends six months on automation, and somehow, magically, will be able to keep automating things and growing things," Balmaseda explained. "We were trying to grow unicorns."
When that predictably failed, they embraced Ansible fully, building features for backups, configuration checks, compliance, and OS upgrades. They leveraged vendor collections from Cisco, Arista, and F5, eventually building their own collection when Ansible 2.10 arrived.
But then they hit the wall.
Why Ansible Wasn't Enough
The problems were painfully familiar:
Performance issues: Backups took seven hours to complete
Complex data structures: Nearly impossible to handle without filters
Debugging nightmares: "The debugging in Ansible is a pain. I will defend this to death."
Memory consumption: Mysterious overnight failures that took weeks to diagnose
Architecture chaos: Roles calling roles calling filters in an unmaintainable mess
The breaking point came when their backup process mysteriously started failing overnight. "We got no output from Ansible saying why. It took us two to three weeks to realize there was a huge peak in memory consumption, overflowing our workers."
The Software Development Approach
Instead of fighting tools designed for simple tasks, they shifted to treating infrastructure automation as genuine software development, implementing a Model-View-Controller (MVC) architecture:
Models: Handle interactions with physical devices through proper class hierarchies with reusable methods that cascade down to specialized implementations.
Controllers: Perform small, focused tasks using the models—simple tasks that are easy to follow and test.
Views: The products exposed to users, orchestrating controllers without ever talking directly to models.
Separation of Expertise
Rather than creating unicorns, they focused on what each team does best:
Software Developers Lead: Architecture, code quality, CI/CD processes, maintainability, and scalability.
Network Engineers Lead: Network knowledge, abstractions, requirements definition, and operational expertise.
The bridge between teams? A product owner with sufficient knowledge of both domains to facilitate communication.
"We want the network engineers to be the ones providing really useful information about the network," explained Villegas. "And we want to be the ones leading the software development because that's what we know best."
Practical Implementation
Their "massive change" product exemplifies this approach. Network engineers define changes using JSON files and Jinja2 templates, specifying:
Configuration to be applied
Pre-conditions that must exist
Configurations that cannot be present
Post-validation requirements
Engineers simply clone repositories, add their abstractions, and submit merge requests. The software team handles code quality, testing, and deployment automation.
"You make that into a merge request, we approve it (or we don't!), and that's available for everyone to use on our platform."
The Results
The transformation delivered dramatic improvements:
Performance: Backups dropped from seven hours to 20 minutes—a 21x improvement.
Onboarding: New team members contribute meaningful code within 2-3 weeks instead of 6-8 months.
Scale: 200 device upgrades completed in one weekend without logging into a single device.
Harmonization: Configuration changes can be applied to hundreds of devices within minutes.
User Experience: Network engineers get pre-check results, upgrade status, and post-check validation through a simple interface.
Beyond Automation: Building Systems of Record
Their next phase involves creating comprehensive systems of record for network state. Using Nautobot with custom plugins, they're modeling complex BGP routing relationships and AS number allocations.
"If something is in the tool, it's because it's already in the network," Villegas explained. "People are delighted because they don't need to look for weird spreadsheets or log into devices. It's just there, synchronized."
The ultimate goal? Reversing the arrow—making the system of record the authoritative source that drives network changes, not just reflects them.
Key Principles
Software Serves the Network: "We cannot change anything just to cope with an out-of-the-box tool. We've had to build our own. We've made software a service to the network."
Object-Oriented Design Works: "Why? Because it works. It's been working for years, and it works for us. We can easily abstract what we need, extend what we need."
Don't Reinvent Wheels: "If a vendor comes with tools that work for us, we'll adapt to those tools while maintaining the same framework and interfaces."
No Mandatory Adoption: Engineers can still use CLI when needed. Automation augments rather than replaces human judgment.
The Bigger Picture
What makes their approach compelling isn't just the technical architecture—it's the honest acknowledgment that network automation is software development. Instead of pretending otherwise or trying to transform domain experts into something they're not, they embraced specialization.
"We are building 100% professional software following industry trends," Balmaseda concluded. "We are offering to network engineers—some being users, some being contributors—but we are doing software."
This isn't about replacing network engineers or diminishing their expertise. It's about leveraging that expertise more effectively by surrounding it with proper software development practices.
As they've proven at Roche with their heterogeneous, multi-vendor global network, sometimes the answer isn't better automation tools—it's better software engineering applied to automation challenges.
The unicorns aren't disappearing. They're just working alongside horses and rhinos, each contributing what they do best.
Watch the full presentation: Coding for Infrastructure is Just Coding
