The Car Analogy: Why Network Abstraction Matters More Than You Think
Summarizing Jaakko Rautanen's abstraction approach from AutoCon3
"When we drive a car, do we think about every detail the car has? Every part?" asked Jaakko Rautanen, opening with a deceptively simple analogy. "We don't. Instead, we just think about steering wheel, pedals, and dashboard. But the details of the car still matter—somebody has designed them and made them work together."
His presentation on network abstraction offered a compelling vision: instead of manual box-by-box configuration or even partially automated operations that still require engineers to "think way too many details in daily operations," we can model our network services and let automation run the model for us.
The Starting Point: Partial Automation Isn't Enough
Rautanen's team supported dedicated networks for media systems—high-bandwidth, feature-rich connections between studios and delivery systems. They had already moved beyond manual configuration, implementing NetBox with automated configuration pipelines. But they identified two critical problems:
Detail Overload: "It didn't make sense that we moved from manual box configuration to some central system and still played with all the details every day."
Pipeline Complexity: Their Ansible-based configuration pipeline expected arbitrary tags from NetBox to trigger additional configuration on-the-fly. "That playbook was getting extremely complex to handle."
They had solved the obvious automation problem but created new complexity challenges.
The Two-Part Solution
Outbound (NetBox to Devices): Implement a "straight pipe" approach with no modifications to data content during the pipeline. Format might change, but content remains untouched.
Inbound (Human to NetBox): Create higher abstraction levels that populate detailed data automatically rather than requiring manual entry of every configuration detail.
The Automation Stack Architecture
Their solution created a four-layer stack:
Abstraction Layer: Abstract services implemented as NetBox plugins
Detailed State: NetBox's native models populated automatically by the abstraction layer
Vendor Transformation: Data converted to vendor-specific formats
Device Pipelines: Vendor-specific deployment mechanisms
When you add an abstract service instance, it automatically populates "lots of detailed data in the detailed state of the network," eliminating manual detail management.
Practical Example: Virtual Network Service
Rautanen demonstrated with a "virtual network" service—essentially an MPLS Layer 3 VPN with customer site connections. The manual approach required correctly allocating and configuring numerous green-highlighted details: VLANs, interfaces, IP addresses, routing configurations, and more.
Their abstraction split this into two models:
Virtual Network Type: The service model
MPLS Site: Connection points that can be linked to multiple virtual networks
The User Experience: Adding a virtual network requires only two mandatory parameters—name and template reference. Optionally, attach it to specific sites.
The Automation Result: Clicking "create" automatically generates AS numbers (allocated from template ranges), VLANs, transit prefixes, loopback interfaces, VLAN interfaces, subinterfaces, and all associated IP addressing.
"We didn't have to think about them, but we can see every detail if we want to."
Visualization and Deployment
Their recently open-sourced NetBox plugin called "Ninja" renders real-time network diagrams based on NetBox data. Every element—device names, prefixes, interface names—is clickable, linking back to NetBox views.
The configuration pipeline plugin shows exactly what will change before deployment. In their example, 500 lines of configuration across multiple devices, with device-specific line-by-line previews available before hitting "push" to deploy to production.
Design Process and Principles
Split the Problem: Decompose complex services into manageable components with clear relationships.
Model Each Part: Define relationships, fields, object references, and types for each component.
Implement Logic: Add allocation algorithms (like AS number assignment) and business rules.
Iterate: Move between top-down and bottom-up perspectives until the design coheres.
Developer Handoff: Network engineers design; developers implement with proper software engineering practices.
Key Lessons Learned
1. Eliminate Arbitrary Rules
"As network engineers, we're really good at inventing arbitrary rules," Rautanen observed. "We encode arbitrary information into IP addresses and VLAN IDs. Network engineers can even code their shoe sizes into IP addresses."
In automated environments, most arbitrary encoding rules become unnecessary complexity. Some rules remain useful for clarity, but far fewer than manually managed networks require.
2. Follow Declarative Models
Inspired by Roman Dodin's previous AutoCon presentation, they implemented full configuration replacement: "When we push configuration to network devices, we replace the entire configuration every time."
This approach eliminates complex logic about what to add or delete—the device figures that out. It also solves configuration drift automatically: "What drift? Every time you push, you override the entire configuration."
Engineers understand this model: manual changes must be reflected in NetBox or they'll be overwritten on the next push.
3. Make Models Generic and Flexible
Early models were "quite case-specific and fixed, hard-coded." Experience taught them to add templates for almost every service model, enabling network administrators to create different use cases without coding.
"This makes it really easy for network admins to add a couple of templates for different use cases without need to code."
Addressing Abstraction Concerns
When asked about preventing abstractions from becoming limiting paradigms (like cloud provider constraints), Rautanen acknowledged the challenge: "Sometimes there is debate how to do those abstractions."
His approach: ensure abstractions model how the network should actually work, maintain simplicity while covering use cases, and be prepared to modify abstractions when requirements change.
"We try to make them work as the network is supposed to work, try to model that."
CLI Access and Cultural Change
Interestingly, they don't prevent CLI access. Engineers can still log in and make manual changes, but cultural understanding ensures they handle the implications properly.
"They know that if they leave something for their colleagues to handle, that's kind of a really bad thing," Rautanen explained. This social contract prevents configuration drift issues without technical enforcement.
The Bigger Picture
Rautanen's abstraction approach addresses a fundamental automation challenge: moving beyond tool proliferation toward conceptual simplification. Rather than teaching engineers more complex tools, they created simpler interfaces that hide complexity without eliminating capabilities.
This represents a maturation of automation thinking—from "how do we make configuration faster" to "how do we make network operations conceptually simpler while maintaining full control."
The car analogy proves apt: drivers don't need to understand internal combustion engines, but someone designed those engines to work reliably. Similarly, network operators shouldn't need to think about VLAN allocation algorithms, but someone should design those algorithms to work reliably.
Why This Matters
As network automation tools proliferate, the risk grows of creating more complexity rather than less. Rautanen's approach suggests that successful automation requires thinking beyond tool integration toward service modeling and abstraction design.
The question isn't just "how do we automate our network configurations" but "how do we model our network services so that automation becomes invisible and inevitable?"
His team's journey from complex Ansible playbooks to simple service creation forms illustrates this evolution. By focusing on abstraction design rather than just automation tooling, they achieved the original promise of automation: making complex operations simple rather than making simple operations automated.
As he concluded: "Start to explore higher levels of abstraction." The future of network automation might not be about better tools—it might be about better models.
Watch the full presentation: Mastering Network Operations: The Power of Abstraction
