Infrastructure as Code: Stop Fixing Networks (Start Replacing Them)

IaC Series – Issue 5 of 6: When Your Network Becomes Software

🧠 The Old Way: “Just Fix the Network”

Something breaks.

• VLAN isn’t passing traffic

• Firewall rule isn’t hitting

• BGP neighbor flaps

• Random site can’t reach one specific app (of course)

So what do we do?

We jump into the controller or device:

• Add a quick rule

• Tweak a VLAN

• Bounce an interface

• Change a route

• Maybe disable something “temporarily”

And then…

👉 It works

And we move on with our lives like heroes.

---

💀 The Problem Nobody Talks About

That “quick fix” you just made?

It probably:

• Exists only in the device/controller

• Isn’t in Git

• Isn’t documented

• Isn’t consistent across sites

• Won’t be there in DR

• Won’t be there in the next deployment

You didn’t fix the network.

👉 You forked reality

---

❄️ Welcome to Snowflake Networking

Now your environment looks like this:

• Site A → has the “fix”

• Site B → doesn’t

• Firewall → slightly different

• Templates → “almost” correct

• Controller → source of confusion, not truth

And 3 months later:

“Why does this only break at one location?”

Because past-you was moving fast and feeling dangerous.

---

🔥 The IaC Mindset Shift

Here’s the uncomfortable truth for network engineers:

❌ Devices are not the source of truth
❌ Controllers are not the source of truth
❌ Templates are not the source of truth

Yeah… even that shiny dashboard you trust.

Instead:

✅ Code is the source of truth
✅ The network is just a deployed result
✅ Changes happen in code first, not the network

---

🧨 The Rule That Changes Everything

If the network breaks, you don’t “fix” it… you redeploy it.

I can already hear it:

“JJ… I’m not redeploying a firewall in prod. Relax.”

Fair.

But stay with me.

---

🏗️ What This Looks Like in Networking

Instead of this:

• Log into firewall

• Add rule

• Test

• Leave it there forever

• Forget to update templates

You do this:

• Update rule in Git

• Commit change

• Pipeline runs

• Push to device group / template / API

• Network converges to desired state

Same outcome.

Completely different control.

---

😬 “But That’s Slower…”

Yeah… the first time.

Because now you have to:

• Define rules properly

• Track changes

• Trust automation

But here’s the tradeoff:

👉 Manual fix = fast once
👉 Code-based deploy = fast every time after that

---

🧠 Why This Matters More for Network Engineers

Sysadmins figured this out years ago.

Network teams?

We’ve been living in:

• Controllers

• GUIs

• “Just one quick change” culture

Which means:

👉 We create drift constantly
👉 And we don’t even notice it

---

😈 The Hidden Benefit

When engineers know:

“If it’s not in code, it won’t survive”

They stop doing:

• “Let me just add this rule real quick”

• “I’ll fix it in the firewall directly”

• “We’ll update the template later”

Because they know:

👉 The next deploy will wipe it out

And suddenly…

✨ Your configs actually stay consistent

---

🧪 Quick Reality Check

Ask yourself:

• If you rebuilt your firewall policies from Git right now… would they match prod?

• If you pushed templates again… would anything break?

• Do you trust your source of truth more than your controller?

If any of those answers feel uncomfortable…

Good.

That’s the point.

---

🔒 Paid Section – Where This Gets Real

🧱 The “Redeploy, Don’t Patch” Pattern for Networks

This is how you actually apply this without nuking production.

---