<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Part 1: Rethinking Networking with Automation on Designing Network Automation at Scale</title><link>https://designingnetworkautomation.com/series/part1-rethinking-networking-with-automation/</link><description>Recent content in Part 1: Rethinking Networking with Automation on Designing Network Automation at Scale</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 19 Aug 2026 14:10:38 +0200</lastBuildDate><atom:link href="https://designingnetworkautomation.com/series/part1-rethinking-networking-with-automation/index.xml" rel="self" type="application/rss+xml"/><item><title>01 - The Automation Imperative</title><link>https://designingnetworkautomation.com/series/part1-rethinking-networking-with-automation/01-automation-imperative/</link><pubDate>Mon, 10 Nov 2025 00:00:00 +0000</pubDate><guid>https://designingnetworkautomation.com/series/part1-rethinking-networking-with-automation/01-automation-imperative/</guid><description>&lt;h1 id="1-the-automation-imperative">1. The Automation Imperative&lt;a class="anchor" href="#1-the-automation-imperative">#&lt;/a>&lt;/h1>
&lt;div class="note-box">
 &lt;em>&amp;ldquo;To automate or not to automate, that is the question.&amp;rdquo;&lt;/em>
&lt;/div>
&lt;p>Ever since &lt;a href="https://designingnetworkautomation.com/glossary/#sdn" class="glossary-term" title="A network architecture approach that enables the network to be intelligently and centrally controlled, or &amp;#39;programmed,&amp;#39; using software applications. This helps operators manage the entire network consistently and holistically, regardless of the underlying network technology.">Software-Defined Networking (SDN)&lt;/a> 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.&lt;/p></description></item><item><title>02 - Design Principles</title><link>https://designingnetworkautomation.com/series/part1-rethinking-networking-with-automation/02-design-principles/</link><pubDate>Sun, 30 Nov 2025 00:00:00 +0000</pubDate><guid>https://designingnetworkautomation.com/series/part1-rethinking-networking-with-automation/02-design-principles/</guid><description>&lt;h1 id="2-design-principles">2. Design Principles&lt;a class="anchor" href="#2-design-principles">#&lt;/a>&lt;/h1>
&lt;p>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.&lt;/p>
&lt;p>Adoption never came. Operators kept using the CLI. When asked why, the answers were consistent: &amp;ldquo;I don&amp;rsquo;t know what it&amp;rsquo;s going to do before it does it.&amp;rdquo; &amp;ldquo;If something goes wrong, I can&amp;rsquo;t tell what happened.&amp;rdquo; &amp;ldquo;I don&amp;rsquo;t understand how to read the output.&amp;rdquo; 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&amp;rsquo;t earned. Six months of engineering effort sat unused.&lt;/p></description></item><item><title>03 - Architectural Thinking</title><link>https://designingnetworkautomation.com/series/part1-rethinking-networking-with-automation/03-architectural-thinking/</link><pubDate>Wed, 10 Dec 2025 00:00:00 +0000</pubDate><guid>https://designingnetworkautomation.com/series/part1-rethinking-networking-with-automation/03-architectural-thinking/</guid><description>&lt;h1 id="3-architectural-thinking">3. Architectural Thinking&lt;a class="anchor" href="#3-architectural-thinking">#&lt;/a>&lt;/h1>
&lt;p>This chapter introduces the foundations of this book. It explains why you need to adopt this mindset, introduces a reference framework proposed by the &lt;a href="https://networkautomation.forum">Network Automation Forum&lt;/a> (NAF), and shows how to leverage it in your projects.&lt;/p>
&lt;p>Part 2 dives deep into these topics. In this chapter, we&amp;rsquo;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.&lt;/p></description></item></channel></rss>