Designing Network Automation at Scale

01 - The Automation Imperative

Mon, 10 Nov 2025 00:00:00 +0000

1. The Automation Imperative#

“To automate or not to automate, that is the question.”

Ever since Software-Defined Networking (SDN) and DevOps arrived, engineers have argued about whether network automation is necessary, a luxury, or just overengineering. The answer? It depends. Hyperscalers need it: they started in the early 2010s because they had no choice. Small businesses might not need full automation at all. Most networks sit somewhere in the middle. Culture, skills, tool maturity, and business priorities all shape how fast you adopt. Today, all those factors are lining up. Automation is becoming inevitable.

02 - Design Principles

Sun, 30 Nov 2025 00:00:00 +0000

2. Design Principles#

A network automation team spent six months building a system they were genuinely proud of. It pulled intent from a structured data model, generated device configurations through a templating engine, validated changes against a policy library, and pushed them via NETCONF with full rollback support. Architecturally, it was solid. The demo to leadership went well. Then they handed it to the network operations team.

Adoption never came. Operators kept using the CLI. When asked why, the answers were consistent: “I don’t know what it’s going to do before it does it.” “If something goes wrong, I can’t tell what happened.” “I don’t understand how to read the output.” The automation team had built something technically impressive but operationally opaque. There was no dry-run mode, no human-readable change preview, no audit trail written in terms operators recognized. The system was a black box that asked for trust it hadn’t earned. Six months of engineering effort sat unused.

03 - Architectural Thinking

Wed, 10 Dec 2025 00:00:00 +0000

3. Architectural Thinking#

This chapter introduces the foundations of this book. It explains why you need to adopt this mindset, introduces a reference framework proposed by the Network Automation Forum (NAF), and shows how to leverage it in your projects.

Part 2 dives deep into these topics. In this chapter, we’ll just present them to give a high-level picture before getting into the weeds. This matters because once we describe each building block, having the overall picture helps you connect the dots.

04 - Source of Truth

Sun, 15 Feb 2026 00:00:00 +0000

4. The Source of Truth#

A new service needed to go live by end of week. The change was straightforward: a new VLAN, a new subnet, updated firewall rules, and a new BGP community on the edge routers. The network engineer knew exactly what to do. What followed was four days of coordination across five systems: the IPAM tool to reserve the subnet, the CMDB to register the service, the firewall management platform to push the new policy, the router configuration system for the BGP community, and the monitoring platform to add the new thresholds. Each system had its own interface, its own data model, its own approval workflow. And because there was no shared reference, the engineer had to carry the context manually: copying values from one system to the next, hoping nothing drifted between steps.

05 - Execution

Sat, 01 Nov 2025 00:00:00 +0000

5. Execution#

The playbook had been running perfectly for months: ten access switches in the lab, two minutes end to end, clean results every time. When the team decided to roll it out to the full inventory of 800 switches, nobody expected trouble. The first 600 devices updated without issue. Then the job slowed. Then it stalled. The RADIUS server, suddenly receiving 150 simultaneous SSH authentication requests, started rejecting connections. Ansible hung on 150 devices mid-execution. An engineer killed the job.

Preface

Sat, 01 Nov 2025 00:00:00 +0000

Preface#

Network automation is no longer a luxury or experimental technology: it has become an operational necessity. From hyperscale data centers managing hundreds of thousands of devices to enterprise networks balancing legacy systems with cloud-native services, the complexity and scale of modern networks demand systematic, architectural approaches to automation.

This book emerges from years of practical experience designing, building, and operating network automation systems across different environments and organizational scales. It represents a synthesis of lessons learned, patterns observed, and principles discovered through real-world implementation of automation platforms.

06 - Observability

Mon, 12 Jan 2026 00:00:00 +0000

6. Observability#

A service provider’s core router had a fan module fail silently overnight. There were no alerts. The thermal management subsystem on the line cards detected rising temperatures and began throttling the forwarding ASICs to protect the hardware. Throughput on a production transit link dropped by 40%. The monitoring system saw nothing: the thermal sensors it polled were on the chassis supervisor, not on the individual line cards. The SNMP polls ran every five minutes and reported the device as healthy. The interface counters showed reduced throughput, but no threshold was configured for that pattern because the link had always been well below capacity.

07 - Orchestration

Fri, 20 Mar 2026 00:00:00 +0000

7. Orchestration#

The network team had done everything right. They had a solid Source of Truth, well-tested playbooks for every operation, and a clear runbook to execute them. On paper, deploying a new VLAN service was fully automated. In practice, it took half a day and one specific engineer.

That engineer knew the sequence. First, validate the SoT data was complete. Then run the pre-check playbook. Then review the output, look for failed devices, and decide whether to continue. Then trigger the deployment playbook. Then wait. Then run the validation playbook. Then update the ServiceNow ticket manually. If any device failed partway through, roll it back before the others noticed. She had it all in a runbook, step by step, in a shared document that nobody else had fully internalized.

08 - Presentation

Sat, 28 Mar 2026 00:00:00 +0000

8. The Presentation Layer#

The VLAN automation had been running for six weeks. The network team was proud of it. Every morning, three or four new service requests arrived from application teams, and the Orchestrator handled them without anyone on the network team touching a keyboard. The deployments worked. The switches were configured. The network was healthy.

The escalation arrived on a Thursday. The application team lead was asking why VLAN requests were taking three to five business days when the portal said “submitted.” The network team checked their queue: zero pending requests, all deployments successful. The automation had processed every request within twenty minutes of receipt. But the ServiceNow tickets still showed “In Progress,” because nobody had written the integration that would update them.

09 - The Network

Sun, 29 Mar 2026 00:00:00 +0000

9. The Network#

The VLAN automation had been running for three weeks in the lab. Three switches, one of each vendor, every workflow passing. The team felt confident. On the first production run, 23 of the 800 campus switches failed. All HPE. All running a firmware version that nobody had documented.

The playbook was checking the error response from each device after pushing the VLAN configuration. On modern HPE firmware, an already-existing VLAN returns the error code duplicate-vlan. On this older firmware version, the same condition returned vlan-exists. The playbook had been written to treat duplicate-vlan as an idempotency signal, meaning “this already exists, that is fine.” It had not been written to handle vlan-exists, so it treated that response as a failure. A third of the HPE fleet reported failure. The rollback ran cleanly. The application team’s ticket stayed open for another three hours while the network team manually audited which switches had actually been configured and which had not.

10 - Platform Engineering and CI/CD

Thu, 16 Jul 2026 00:00:00 +0000

10. Platform Engineering and CI/CD#

A network engineer at a mid-size financial services firm needed to modify a firewall rule to allow a new internal service to reach an authentication endpoint. The change itself took about ten minutes to understand and design. What followed was different. She needed to open a ticket in the ITSM system and fill out a form that asked questions her team had never agreed on. She needed to submit a change request to a separate portal, which triggered a workflow that sent an automated notification to a stale distribution list. She needed to manually run a validation script on her laptop, copy the output into a comment on the ticket, and wait for a reviewer to read it.

11 - Scaling and Reliability

Thu, 16 Jul 2026 00:00:00 +0000

11. Scaling and Reliability#

The firmware upgrade had been planned for three weeks.

Eight hundred campus switches, three vendors, a maintenance window from midnight to 6 AM. The automation platform was well-tested on the campus fleet. The team had run smaller upgrades through it before. Forty-eight workers ran in parallel, chosen to balance speed against device load. At midnight, the job started.

By 2:14 AM, 47 of the 48 workers had completed. Seven hundred and eighty-seven switches had been upgraded successfully. The forty-eighth worker was still running. The orchestrator showed it as active; no error had been raised. One of the devices it was targeting was not responding to any management plane query, but it had not explicitly rejected the connection either. The worker was waiting for a response that was not going to arrive.

12 - Security, Governance and Compliance

Thu, 16 Jul 2026 00:00:00 +0000

12. Security, Governance and Compliance#

The audit finding arrived on a Tuesday morning.

A PCI compliance review had examined six months of firewall change history across the organization’s network. The auditors had a straightforward request. For each of the firewall changes: who authorized it, what change ticket it was associated with, evidence that pre-deployment validation occurred, and the network state before and after.

The automation platform had made 847 changes to the firewall configuration during those six months. It had made them correctly. The validation logic had been tested and applied. The rollback procedures had worked in the two cases where they were needed. No production incident had been caused by automation during that period. By every operational metric, the platform had performed well.

13 - Cultural Shift

Sun, 19 Apr 2026 00:00:00 +0000

13. The Cultural Shift#

The meeting invite arrived on a Thursday, titled “Network Team Structure Update”. Jordi had been a network engineer for fifteen years. He had his CCIE. He had survived three acquisitions, two NOC consolidations, and one BGP routing incident so severe it became an internal case study. He assumed this was a staffing update.

It was not.

His manager explained that the network team was being reorganized under Platform Engineering. The team’s name would change to Network Automation Platform. The work would evolve: less manual provisioning, more building and operating the automation systems that handled provisioning. The new job description was already written. It was titled “Network Platform Engineer”.

14 - Automation as a Product

Tue, 05 May 2026 00:00:00 +0000

14. Automation as a Product#

Six months before the conversation that changed how the team thought about their work, the network platform team had delivered something genuinely impressive. Two years of consistent effort had produced a provisioning platform that handled branch onboarding end to end: a self-service interface for site requests, a closed-loop validation workflow that caught misconfigurations before deployment, and an operational dashboard that tracked service health across three hundred locations. The team had gone from twenty-four-hour change windows to forty-minute automated deployments. They were proud of it, and they should have been.

15 - Closed-Loop Automation

Sat, 18 Jul 2026 00:00:00 +0000

15. Closed-Loop Automation#

The content network had thirty points of presence scattered across the globe, and every one of them reached its users the same way: over the public internet, through a handful of ISPs. Usually three, sometimes four (plus a handful of local peerings). Some were global Tier 1 transit; some, in regions that offered nothing better, were regional local providers. Under normal operations, each point of presence spread its users across all of its ISPs at once, because it needed every one of them to carry the traffic it saw, and Border Gateway Protocol (BGP) decided which users rode which ISP, with the usual local-preference values and community tags.

16 - Self-Healing Networks

Sat, 18 Jul 2026 00:00:00 +0000

16. Self-Healing Networks#

At 09:40 on a weekday, one of the Amsterdam point of presence’s ISPs started to go bad. Not down, bad. Somewhere inside that ISP’s network, well past the peering point, something began degrading the flows that crossed it. At Amsterdam’s edge nothing looked wrong: the Border Gateway Protocol (BGP) session stayed up, no BFD session dropped, the interface counters showed no loss, the running configuration matched intent exactly, and the closed loop from Chapter 15 reported no drift. By every signal the network owned, that ISP was healthy.

17 - Autonomous Networks

Sat, 18 Jul 2026 00:00:00 +0000

17. Autonomous Networks#

The traffic optimizer was supposed to save money. The network’s ISPs did not all cost the same; at many points of presence one provider was roughly 30% cheaper per bit than the others, and most nights the network ran well under capacity. So the team added an optimizer that re-planned, during the low-traffic window, how each point of presence spread its users across its ISPs, shifting more of them onto the cheaper providers wherever the paths were good enough. It worked. The monthly transit bill dropped, and for some weeks nothing went wrong.

Christian Adell

Sat, 01 Nov 2025 00:00:00 +0000

About Christian Adell#

Staff Network Developer at CoreWeave | Barcelona, Spain

Christian Adell has developed his career around software development applied to network automation. He has extensive experience in designing and implementing network automation solutions at scale.

📞 Contact#

GitHub: chadell
LinkedIn: christianadell
Twitter: @chadell0

📖 Published Books#

Christian is the author and co-author of several influential books on network automation:

Network Programmability and Automation, 2nd Edition

Network Automation with Nautobot

Modern Network Observability

Network Automation Cookbook, 2nd Edition

🎤 Speaking & Community Engagement#

Christian is an active speaker at major networking conferences and community events:

About / Copyright

Mon, 01 Jan 0001 00:00:00 +0000

Copyright Notice#

The content on this site, including text, diagrams, and examples, is the intellectual property of the author under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License (CC BY-NC-ND 4.0).

You are free to

Share — copy and redistribute the material in any medium or format, with proper attribution

Under the following restrictions:

Attribution — You must give appropriate credit to Christian Adell Querol, provide a link to the license, and indicate if changes were made.
NonCommercial — You may not use the material for commercial purposes.
NoDerivatives — You may not remix, transform, or build upon the material for distribution.

Important Notes