Infrastructure as Code: Why Most Networks Are Still Built Like It's 2005
IaC Series – Issue 1 of 6: When Your Network Becomes Software
You inherit a network.
The documentation is outdated.
Half the switches have configs that don’t match each other.
There’s a firewall rule nobody understands but everyone is afraid to delete.
Someone tells you:
“Don’t touch that. It’s been like that for years.”
So you do the only thing network engineers have done for decades.
show runYou scroll.
You search.
You try to reverse-engineer the history of the network from the running configuration.
Welcome to traditional infrastructure management.
And whether we like it or not, this is still how most networks operate today.
The Snowflake Infrastructure Problem
For a long time, infrastructure was built the same way most home labs are built.
One device at a time.
An engineer logs in, configures something, saves the config, and moves on.
Over time, every device becomes slightly different.
Different VLAN names.
Different ACL structures.
Different routing policies.
No two devices are exactly the same.
Every server, switch, and firewall becomes a special little snowflake.
Unique.
Fragile.
And terrifying to rebuild.
The “Just SSH In Real Quick” Culture
Most infrastructure teams developed a habit that still exists today.
Something breaks.
An engineer logs into the device.
They make a change directly on the CLI.
Problem solved.
Until six months later when someone else asks:
“Why is this configured like this?”
And the only documentation available is:
show running-configThis approach worked for a long time because networks were smaller, simpler, and changed less frequently.
But modern infrastructure moves faster than manual configuration can keep up.
Software Engineers Solved This Problem Years Ago
Here’s where things start to look strange from the infrastructure side.
Software engineers can rebuild an entire application from a Git repository.
Every dependency.
Every configuration.
Every version.
If their production server disappears, they don’t panic.
They redeploy it.
Infrastructure teams, on the other hand, often can’t rebuild a single switch configuration without digging through backups, documentation, and tribal knowledge.
That difference is exactly what Infrastructure as Code was created to solve.
What Infrastructure as Code Actually Means
Despite the buzzwords, Infrastructure as Code is a simple idea.
Infrastructure should be defined in code and reproducible from source control.
Instead of logging into devices and configuring them manually, the configuration lives in a repository.
Changes are tracked.
Versions are recorded.
Deployments are automated.
The infrastructure becomes something you can rebuild instead of repair.
In other words:
Your network stops being a collection of mystery configurations and starts behaving more like software.
Why Network Engineers Struggle With IaC
Infrastructure as Code sounds simple, but for many network engineers it feels unnatural at first.
Networking has historically been built around direct device access.
CLI commands.
Vendor GUIs.
Manual configuration.
Automation tools came later.
And even today, the instinct when something breaks is still:
“Let me SSH in real quick.”
Infrastructure as Code flips that model.
Instead of fixing things manually, changes happen through code and automation.
Which means the CLI stops being the primary tool for managing infrastructure.
For many engineers, that’s a major shift in how operations work.
What Infrastructure as Code Is NOT
A lot of teams believe they’re doing Infrastructure as Code when they really aren’t.
IaC is not:
• Running scripts occasionally
• Copy-pasting configs through automation
• Using Ansible once in a while
• Storing backups in Git
Infrastructure as Code is about desired state and reproducibility.
If a device disappears, you should be able to recreate it from the code.
No guessing.
No archaeology.
No asking the engineer who configured it three years ago.
Just code.
The Real Goal of IaC
The goal of Infrastructure as Code is simple.
If a switch, firewall, or server disappears tomorrow…
You should be able to rebuild it from Git.
Not rebuild it approximately.
Not rebuild it close enough.
Rebuild it exactly.
That’s when infrastructure stops being fragile and starts being reliable.
What Comes Next
Once infrastructure is defined in code, a new set of concepts appears that can be confusing at first.
Terms like:
Declarative
Imperative
Idempotent
State
These ideas are at the core of how modern infrastructure automation works.
And understanding them is what separates simple automation from true Infrastructure as Code.
In the next issue, we’ll break down one of the most misunderstood concepts in automation:
Declarative vs Imperative infrastructure.
Because understanding that difference is where Infrastructure as Code really starts to make sense.
Want the deeper dive?
Most teams trying Infrastructure as Code fail for the same reason.
They try to automate infrastructure without changing how the team operates.
The result is predictable.
The code says one thing.
The infrastructure slowly becomes something else.
Eventually nobody trusts the automation anymore.
In the Extended Version, we break down:
• The real test that proves whether your infrastructure is reproducible
• The biggest mistake teams make when adopting IaC
• How Git becomes the control plane for infrastructure
• Why automation fails when manual changes are still allowed
If you’ve ever inherited a network where nobody knows why half the configs exist, the extended version will feel painfully familiar.
— JJ – Chief Packet Pusher.