Networks, Automation, Connectivity & Data Centres · Chapter 15 of 18
Network automation at scale
What teams actually run, why the source of truth decides whether the programme survives, and the failure mode that has no analogue on a server.
Network automation is discussed as a tooling question and is almost never lost on tooling. The best practitioner survey available — 681 responses across 58 countries — puts 44% of stated barriers in the ‘people’ category (skills, organisational, cultural) against 10% technical, and the technical share fell year on year.
What teams actually run
| Share of mentions | Read | |
|---|---|---|
| Python | ~93% of language mentions | The lingua franca. Not in dispute |
| Ansible | ~53% of open-source tool mentions | The mainstream by a wide margin |
| NetBox | ~28% | Source of truth, and the second most-mentioned tool overall |
| Nautobot | ~16% | The fork that became an automation platform — jobs and golden-config in the same place |
| Nornir | ~12% | A strong minority tool for teams with real Python skill |
| Terraform | ~11% | Mostly for the cloud and controller-API half |
| rancid / oxidized | ~5% combined | Config-backup tools from the 2000s, still polling above NAPALM. Read every 'the industry has moved to model-driven automation' claim against that |
And the maturity number is the one to carry: mean automation across respondents is about 37%, median 30%, with roughly three-quarters of teams at or below half automated and about 5% above 90%. The median network team is doing config templating and backups, not intent reconciliation.
Why the source of truth is the whole programme
A source of truth is not a database. It is an organisational commitment that a named system is authoritative and that the network is wrong when it disagrees.
The database is a week of work. The commitment is a two-year political programme, because the day you declare it authoritative is the day every out-of-band change becomes a defect with somebody's name on it.
The supporting evidence is stark: analyst research finds roughly 80% of teams have a network source of truth and only about 20% consider it effective.
Three ways it dies, none of them tooling. Brownfield seeding — you import a network nobody fully documented, the import is 85% right, the 15% is invisible, and the first automated push causes an outage. Trust is gone permanently. Reconciliation direction is never decided — when the model and the device disagree, does discovery overwrite intent or does intent overwrite the device? Per field. Teams that never answer this build a system authoritative for nothing. And partial coverage is worse than none — a model covering 60% of config means every change must reason about the 40% it cannot see, which is harder than manual operation, so people route around it.
The three questions to answer in writing before any code: which fields does the source of truth own? On disagreement, who wins? And what happens to a line nobody owns — preserved, reported, or deleted?
Why idempotency is much harder on a switch than a server
- The config is an ordered document, not a set. ACL entry order, route-map sequence and prefix-list ordering are semantic. ‘Ensure present’ is undefined without a position.
- Many platforms have no transaction. Classic command-line devices apply line by line, so a failure at line 7 of 12 leaves a state that is neither the old one nor the new one. Candidate-config platforms with a commit step are a different world, and you will have both in the same estate.
- Read-back is normalised. You send one form, the device stores and returns another. Naive string diffing reports a change forever, so every mature tool carries a per-platform normaliser and every normaliser has gaps.
- Secrets never compare equal. You push plaintext, the device stores a hash. The diff is permanently dirty unless you special-case it — and the special case is where teams accidentally disable change detection altogether.
- Applying identical config can still be disruptive. Re-applying an interface stanza can bounce the link; re-applying a neighbour can reset the session. Idempotent text does not imply idempotent side effects, and this one has no real analogue in server configuration management.
- Multiple writers, no lock. Your automation, the authentication system, the access-control platform, the monitoring tool and three humans all write to the same running config with no coordination primitive.
A green run is a claim by your tooling, not evidence about the device
This is not hypothetical. A widely-used networking collection carried a defect where its config module, on platforms whose driver supported neither on-box diff nor generated diff, reported success and never pushed the configuration at all. It was fixed in mid-2026, and the same release added a hard failure “instead of silently pushing configuration” when the connection's capabilities could not be determined.
For an unknown period, green pipelines proved nothing on those platforms.
So the only trustworthy definition of a successful change is a post-change read of device state — neighbour counts and states, interface operational status, route counts within expected bounds, error and discard deltas — not the exit code of your automation.
And the corollary for testing: the same tooling can render config offline and parse existing config offline, with no device involved. That means a full unit-test suite for your automation content needs no lab hardware at all. It is the highest-leverage under-used feature in the whole stack, and most teams instead test against production.
Where Terraform fits, and where it does not
State helps for the cloud and controller half — virtual networks, subnets, route tables, security groups, DNS, load-balancer objects, and SaaS-controller APIs. These are genuinely created and destroyed, with stable identifiers, which is what the model assumes.
State actively hurts on physical devices, for four reasons worth being able to state: a router is not a resource you create, so destroying an interface has no sane meaning; partial ownership is the norm and the model assumes exclusive ownership, so an unmanaged neighbouring line looks like drift or gets overwritten; it cannot detect drift on attributes it does not manage, which is precisely where network drift originates; and the state file quietly becomes a source of truth with no schema, no interface and no queryable history.
The clean division: Terraform or its fork for cloud constructs and controller APIs, Ansible or Nornir for device configuration, and a real source of truth feeding both. It is a poor source of truth and an excellent provisioner.
Check yourself