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.

Read more

Everything was working yesterday.

No alerts.
No complaints.
No tickets titled “URGENT: THE INTERNET IS BROKEN AGAIN.”

Then today?

• One site can’t reach another

• A firewall rule “definitely exists” (but somehow doesn’t work)

• That VLAN you swear was there… is gone

• And nobody touched anything… apparently

Yeah. Sure.

Welcome to configuration drift — the silent killer of stable networks.

🧠 What Configuration Drift Actually Is

Configuration drift is what happens when your intended configuration and your actual configuration slowly drift apart over time.

Not because of one big change…

…but because of hundreds of tiny ones:

• “Quick fix” CLI changes

• Emergency firewall rules

• Someone tweaking a port at 2AM

• A “temporary” change that became permanent

• That one engineer who “just logs into the box real quick”

Multiply that across your environment and you get:

“Mostly consistent… except for all the parts that aren’t.”

🧟 The Real Problem: Drift Feels Invisible

Here’s why drift is dangerous:

It doesn’t break things immediately.

It builds slowly. Quietly.

Until one day something depends on a configuration that used to be true…

…and now it isn’t.

That’s when you get:

• “It works in one site but not another”

• “It worked last week”

• “QA works, prod doesn’t”

• “Same config… I think?”

Spoiler: it’s not the same config.

🔥 Real-World Drift Examples

Let’s be honest… you’ve seen at least one of these recently:

Firewall drift
That rule exists… just not on the device you need.

Switch drift
VLAN on the core? Yes.
On the access switch? Not even close.

Cloud drift
Terraform says one thing.
The cloud console says another.

Guess which one is actually running?

“Temporary fix” drift
“We’ll remove that later.”
We did not remove that later.

💀 Why Most Networks Are Drift Factories

Most environments are set up in a way that guarantees drift:

• No true source of truth

• Direct device changes

• Multiple engineers doing their own thing

• No enforced process

• No validation after changes

It’s basically:

“Everyone just try your best and don’t break anything.”

🧩 How IaC Fixes Drift (If You Actually Use It)

Infrastructure as Code doesn’t magically fix drift…

…but it gives you control over it:

• One source of truth (Git)

• Repeatable deployments

• Change visibility

• The ability to compare intended vs actual

But none of that matters if people ignore it.

⚠️ The Part Nobody Likes Hearing

You don’t have a tooling problem.

You have a behavior problem.

You can have:

• Ansible

• Terraform

• Pipelines

• Clean repos

…and still have drift everywhere if people are:

• Logging into devices

• Making “just one quick change”

• Skipping the process

IaC only works when:

Code becomes the ONLY way changes happen.

Not optional. Not “preferred.”

Required.

🧠 The Mindset Shift

Stop thinking:

“The device is the source of truth.”

Start thinking:

“The device is just a deployed artifact.”

If it drifts?

You don’t fix it manually.

You reapply the correct config from code.

🛠️ Quick Win You Can Do This Week

Pick ONE thing you change often:

• Firewall rules

• VLANs

• Interface configs

Then:

1. Export it

2. Put it in Git

3. Treat it as the source of truth

4. Make changes there first

Even if you still apply changes manually…

you’ve already reduced drift.

🔒 Paid Section: How to Actually Kill Drift

Up to this point, you’ve probably realized something uncomfortable:

Your network isn’t broken… it’s just slowly drifting out of control.

And the worst part?

Most teams don’t notice until it turns into:

• a production outage

• a security gap

• or a “this makes no sense” troubleshooting nightmare

💡 Here’s What We’re About to Fix

In the rest of this issue, I’m going to show you exactly how to start controlling drift using the tools you already have.

No enterprise platform required. No massive rebuild.

Just practical, real-world steps.

🔓 What You’ll Learn in the Full Issue

• How to detect configuration drift automatically using Ansible + APIs

• A simple drift audit workflow you can run this week

• How to enforce “no manual changes” without slowing your team down

• A clean, realistic Git + pipeline structure for network configs

• A real-world drift outage scenario (and how it should have been prevented)

If you’ve ever said:

“That shouldn’t have changed…”

This is where you fix that problem for good.

(Unlock the rest below 👇)

Read more

Everything was working.

No alerts. No tickets. No angry Slack messages.

You ran your automation like you’ve done a hundred times before.

And then…

Something disappeared.
Something changed.
Something broke.

And the worst part?

Your automation said everything was successful.

Welcome to state.

What “State” Actually Is (In Human Terms)

When people talk about Infrastructure as Code, they usually focus on:

• Version control

• Repeatable deployments

• Automation

But behind all of that… there’s something quietly keeping score.

State is what your IaC tool believes exists.

Not what actually exists.
Not what was changed 10 minutes ago.
Not what someone “just quickly fixed” in the CLI.

Just… what it thinks is true.

Think of it like this:

State is a network diagram that updates automatically…
but sometimes lies to you with full confidence.

Why State Exists (And Why You Actually Need It)

Before we start blaming state for everything…

It’s doing something important.

Your IaC tool needs to answer three questions:

1. What exists right now?

2. What should exist?

3. What needs to change to get there?

Without state:

• Every run would be a blind push

• Or a full tear-down and rebuild

• Or worse… unpredictable results every time

State is what makes IaC efficient instead of chaotic.

Here’s Where Things Get Dangerous

State works perfectly…

👉 As long as nothing changes outside of it.

And if you’ve worked in networking for more than 5 minutes…

You already know that’s not reality.

Problem #1: Drift (AKA “Who Touched My Config?”)

Drift happens when:

• Someone makes a manual change

• A hotfix gets applied directly

• A controller updates something behind the scenes

Now your real environment ≠ your state file.

So what happens next?

You run your automation again.

👉 And it “fixes” the difference.

Meaning:

Congrats. Your firewall just undid a critical change from two hours ago.

Problem #2: Stale State (Yesterday’s Truth, Today’s Problem)

Sometimes nothing changed manually.

But your state is just… old.

Maybe:

• The last run failed halfway

• The state file didn’t update correctly

• Another process modified things

Now your tool is operating on outdated assumptions.

“I updated the VLAN.”
Cool… except that VLAN hasn’t existed since Tuesday.

Problem #3: Shared State (Team Chaos Mode)

Things get really fun when multiple people or pipelines are involved.

• Two engineers run automation at the same time

• One pipeline overwrites another

• State gets updated mid-run

Now you’ve got:

• Race conditions

• Conflicting changes

• “It worked on my run” arguments

Problem #4: Losing State (The Oh No Scenario)

If your state file disappears or gets corrupted…

You don’t just lose data.

You lose awareness.

Your IaC tool now has no idea:

• What exists

• What it created

• What it should manage

At that point, your options are:

• Rebuild everything

• Or manually figure it out

Neither one feels great.

Why Network Engineers Feel This Pain More Than Anyone

In theory, IaC assumes:

All changes go through code.

In reality, networking looks more like:

• Emergency CLI fixes

• Vendor GUIs making “helpful” changes

• Multiple systems touching the same config

• Partial automation

Which means:

👉 Drift isn’t rare.
👉 It’s constant.

The Real Problem

IaC doesn’t just manage your network.

It manages your understanding of your network.

And if that understanding is wrong…

Everything built on top of it will be wrong too.

What You’ll Learn in the Rest of This Issue

In the full version, I’ll walk you through how to:

• Prevent config drift from silently breaking your environment

• Safely manage state across multiple engineers and pipelines

• Avoid the “automation just wiped my change” nightmare

• Build a workflow that actually works in real-world networks

Because state isn’t the problem.

Ignoring it is.

🔒 Continue Reading (Extended Version)

Let’s Fix This Before It Fixes You

Read more

You start automating your network.

At first, it feels great.

No more clicking around in GUIs.
No more late-night “what changed?” guessing games.

You write a script like this:

• Create VLAN 20

• Assign ports

• Enable trunk

Boom. Automation.

You sit back, sip your coffee, and think:

“Yeah… I’m basically DevOps now.”

Then something weird happens.

You run the same script again…
And now things break.

The Problem You Didn’t Know You Had

Your script isn’t wrong.

It’s just… bossy.

This is what we call imperative automation.

You’re telling the network:

“Do these exact steps. In this exact order. No questions.”

And the network is like:

“Cool… but I already did some of that.”

Now you’ve got:

• Duplicate configs

• Unexpected errors

• Or worse… silent failures

Your automation didn’t fail.

It did exactly what you told it to do.

That’s the problem.

Imperative vs Declarative (The Real Difference)

Let’s make this painfully clear.

Imperative (What most network engineers start with):

create vlan 20
assign ports
enable trunk

You are controlling how the network gets there.

Step by step. Like a checklist.

Declarative (What IaC actually wants):

vlans:
  - id: 20
    name: users

You are describing what the network should look like.

Not how to build it.

Here’s the simplest way to think about it:

• Imperative: “Do these steps.”
  

• Declarative: “This is the outcome — figure it out.”
  

Why Your Scripts Break (Even When They’re “Correct”)

Imperative automation assumes one dangerous thing:

The starting state is always what you expect.

It’s almost never true.

Real networks have:

• Old configs nobody remembers
  

• Manual changes at 2AM
  

• “Temporary” fixes from 6 months ago
  

• That one engineer who “just tweaked something real quick”
  

So when your script runs:

• Maybe VLAN 20 already exists
  

• Maybe ports are already assigned
  

• Maybe the trunk is already enabled
  

Now your script either:

• Errors out
  

• Overwrites something it shouldn’t
  

• Or quietly does nothing useful
  

Declarative Thinking Changes Everything

Declarative systems don’t care how things got messed up.

They only care about one thing:

“Does the current state match the desired state?”

If not… fix it.

If yes… do nothing.

That’s why declarative automation is:

• Idempotent (safe to run over and over)
  

• Predictable
  

• Much harder to break at scale
  

Controllers, Templates… and the IaC Confusion

This is where things get a little awkward.

Because a lot of network engineers think:

“We already have templates. We’re basically doing Infrastructure as Code.”

And to be fair… you’re not wrong.

Tools like:

• Panorama device groups
  

• Aruba Central group configs
  

• Meraki network templates
  

Absolutely make your life better.

They give you:

• Consistency
  

• Centralized management
  

• Less copy/paste chaos
  

Compared to pure CLI chaos, that’s a huge step forward.

But Here’s the Problem

They’re not actually Infrastructure as Code.

They’re centralized configuration.

And that’s not the same thing.

Because in most environments:

The source of truth is still the controller UI.

Which means…

• Someone logs into the controller
  

• Makes a quick change
  

• Clicks commit
  

• Moves on with their day
  

And just like that:

• The network changed
  

• Nobody reviewed it
  

• Nothing was versioned
  

• No one knows why it changed next week
  

This Is Still Imperative Thinking (Just With a GUI)

Even with templates, you’re still doing this:

“Go into the controller and make this change.”

That’s imperative.

You’re still telling the system how to change, not defining what it should be.

What IaC Actually Changes

Infrastructure as Code flips the model.

Instead of this:

“Log into the controller and update the template”

You do this:

• Define config in a repo
  

• Submit a change
  

• Review it
  

• Merge it
  

• Let automation push it
  

Now the flow becomes:

Code → Automation → Controller → Devices

Not:

Engineer → Controller → Hope nothing breaks

The Controller’s New Job

In IaC, the controller doesn’t disappear.

It just gets demoted a little 😄

It becomes:

A deployment platform — not the source of truth

Why This Matters More Than People Realize

Because without this shift, you still have:

• No real version control
  

• No safe rollback
  

• No audit trail that actually helps
  

• No guarantee your “template” matches reality
  

You’ve improved consistency…

But you haven’t solved control.

⚠️ Where This Starts Getting Interesting

Because once you stop telling the network how to change…

And start defining what it should be…

You run into a new problem:

How do you actually enforce that state safely?

🔓 What Paid Subscribers Get in This Issue

If your automation only works when you babysit it…
this is the part you don’t want to miss.

In the rest of this issue, I break down:

• How to make imperative tools (like Ansible) behave like declarative systems

• The 3 rules that turn fragile scripts into safe, repeatable automation

• Real-world patterns for checking state before making changes

• How to stop writing “run once and pray” automation

• Why most network automation fails silently—and how to fix it

This is the difference between:

“I have scripts”

and

“I have automation I actually trust in production”

Read more

Every device becomes slightly different.

Configs drift.
Documentation gets outdated.
And the only reliable record of the infrastructure becomes the running configuration on the device.

Infrastructure as Code attempts to solve that problem.

But understanding IaC requires thinking about infrastructure in a completely different way.

Instead of asking:

“How do we configure this device?”

IaC asks a different question:

“How do we recreate this infrastructure from scratch?”

That shift in thinking is where most teams struggle.

The Real Test of Infrastructure

A good way to understand Infrastructure as Code is to imagine a simple scenario.

A core switch fails.

Completely dead.

No configuration backup available.

Read more

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 run

You 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-config

This 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.

Prod is down.

Someone says, “But the build passed.”

And now you’re staring at a dashboard like it personally betrayed you.

This is the finale of the CI/CD series.

We’ve covered what CI actually means.
We’ve separated Delivery from Deployment.
We’ve talked about pipelines for infrastructure — not just app dev.

Now we’re going to fix the r…

Read more

All checks passed.
Linting? Clean.
Validation? Successful.
Approval? Clicked.

And then production immediately fell over like a folding chair at a backyard BBQ.

If the pipeline was green… how did prod still catch on fire?

Welcome to the finale of the CI/CD series.

Today we’re talking about the uncomfortable truth:

Your pipeline might be lying to you.

Lie #1 — “All Tests Passed”

This one feels comforting.

“All tests passed” sounds like:

• We’re safe.

• We’re mature.

• We’re DevOps now.

But what did those tests actually test?

For infrastructure teams, most pipelines check structure — not intent.

Examples you’ve probably lived through:

• Ansible syntax check passes… but you referenced the wrong variable group.

• Terraform validates… but your plan destroys the wrong resource.

• Firewall rules commit cleanly… but you just shadowed a critical ACL.

• YAML lints perfectly… and still points production traffic to the wrong subnet.

Passing lint is not the same thing as validating logic.

A syntax check will happily confirm that your disaster is formatted correctly.

Most infrastructure pipelines prove that the config is legal.

They do not prove that it is smart.

Lie #2 — “It Worked in QA”

Ah yes. QA.

Where everything works.

Because QA:

• Has fewer devices.

• Has less traffic.

• Has no mystery static routes from 2011.

• Doesn’t have that one undocumented NAT rule nobody wants to touch.

Production is messy.

It has history.
It has hotfixes.
It has “temporary” changes from five years ago.

And if your environments drift — which they absolutely do — then “it worked in QA” just means:

“It worked in a cleaner universe.”

Environment drift is one of the biggest lies pipelines hide.

Your CI/CD process assumes parity.

Your network does not.

Lie #3 — “We Have a Pipeline, So We’re Mature”

This one hurts.

Some pipelines exist for one reason:

To push changes faster.

That’s it.

No diff validation.
No policy enforcement.
No blast radius awareness.
No rollback plan.
No drift detection.

Just:

Push button → Deploy everywhere → Hope.

If your pipeline’s only job is to move changes faster, it’s not CI/CD.

It’s a cannon.

Speed without guardrails is not maturity.

It’s automation with confidence issues.

Lie #4 — “Green Means Safe”

Dashboards are addictive.

Big green checkmarks.
Happy pipeline stages.
Pretty graphs.

But green only means:

“The steps we defined completed successfully.”

If the steps are shallow…
The green is meaningless.

You can have:

• Zero validation of route impact.

• Zero awareness of overlapping firewall rules.

• Zero health checks after deployment.

And still get a big green check.

Your pipeline doesn’t know your business impact.

It only knows the commands it ran.

So What Makes a Pipeline Honest?

An honest pipeline does more than execute.

It questions the change.

At a high level, honest infrastructure pipelines include things like:

• Pre-change diffs reviewed before apply.

• Policy checks (not just syntax checks).

• Approval gates with context.

• Rollback strategies that are real — not “revert manually.”

• Drift detection that catches CLI hotfixes.

• Post-deploy validation (connectivity, routing, service health).

Honest pipelines try to break your change before production does.

They are guardrails — not speedrun buttons.

The Real Goal of CI/CD (For Infrastructure)

CI/CD is not about deploying faster.

It’s about feedback.

It’s about safety.

It’s about visibility.

It’s about being able to answer:

• Who approved this?

• What changed?

• Why did it change?

• Can we roll it back?

• Does production actually match Git?

Automation doesn’t remove responsibility.

It removes excuses.

Want to Build a Pipeline That Doesn’t Lie?

In the Extended Version, I break down:

• The four levels of infrastructure pipeline maturity

• What real CI looks like for Ansible, Terraform, and firewall changes

• Drift detection patterns most teams ignore

• Blast radius awareness before deployment

• Rollback strategies that don’t require panic

• A practical CI/CD self-assessment checklist you can use immediately

If your pipeline is green but prod still makes you nervous…
that version is for you.

That’s the finale of the CI/CD series.

You don’t need trendier tools.

You need stricter feedback loops.

And maybe fewer green checkmarks you don’t trust.

— JJ – Chief Packet Pusher

CI/CD is not Jenkins.
It’s not GitHub Actions.
It’s not a green checkmark.

And it’s definitely not “auto-deploy everything and hope for the best.”

Now let’s talk about what CI/CD actually looks like when the thing you’re deploying can take down an entire region.

Read more

• A microservice

• A Docker build

• 47 unit tests

• And someone in a hoodie saying “we deploy 200 times a day.”

Cool.

Now try doing that with a firewall.

“CI/CD” Hits Different in Infrastructure

In app dev land, if something breaks, you roll forward, patch it, redeploy.

In infrastructure land, if something breaks:

• The network is down

• The VPN is down

• DNS is down

• Or worse… everything is kind of up but nothing works

There’s no blue/green deployment for a core switch.

There’s just you…
And a change window…
And the sound of your heartbeat in your ears.

The Lie We’ve Been Sold

Most CI/CD content assumes:

• Stateless workloads

• Rapid iteration

• Disposable environments

Infrastructure is none of those things.

Your firewall rules aren’t disposable.
Your BGP config isn’t a feature flag.
Your core switch is not “just another container.”

Yet we keep trying to copy/paste app-dev CI/CD patterns into infrastructure teams and wondering why networking and security people panic.

So What Is CI/CD for Infrastructure?

Let’s translate this into sysadmin language.

CI for Infra = Validation Before Damage

Continuous Integration for infrastructure is not about deployments.

It’s about feedback.

Before anything touches prod, your pipeline should:

• Lint your Ansible playbooks

• Validate Terraform syntax

• Check required variables

• Catch obvious config mistakes

• Show you the diff

CI for infrastructure means catching broken configs before you reload prod.

If your “CI” step only checks YAML formatting…
That’s not protection.
That’s spell check.

CD for Infra = Ready, Not Reckless

Continuous Delivery does not mean “auto-push-to-prod.”

It means:

• The change is validated

• The diff is visible

• The blast radius is understood

• The rollout is controlled

CD in infrastructure is about being ready to deploy safely, not racing to deploy automatically.

If your pipeline auto-applies firewall rules with no approval gate…

That’s not maturity.

That’s optimism.

Pipelines Are Guardrails, Not Speedrun Buttons

Some teams treat pipelines like this:

“The faster we can push changes, the more DevOps we are.”

Infrastructure doesn’t reward speed without control.

A good infra pipeline should:

• Block risky diffs

• Highlight rule explosions

• Catch missing variables

• Detect config drift

• Force visibility before impact

It should slow down disasters.

Not accelerate them.

If your pipeline is just a dashboard that turns green…
But no one actually reads the output…

It’s decoration.

Why GitOps Makes Auditors Weirdly Happy

Here’s the part no one tells you:

Auditors don’t care about your YAML elegance.

They care about:

• Who changed this

• When they changed it

• Who approved it

• And how you can roll it back

When your infrastructure lives in Git:

• Every change has history

• Every diff is reviewable

• Every approval is traceable

• Every rollback is possible

GitOps isn’t about buzzwords.

It’s about making auditors slightly less suspicious of you.

Which, frankly, is a win.

The Infrastructure Reality Check

CI/CD for infra is:

• Slower than app dev

• Higher stakes than app dev

• Less flashy

• Way more stressful

But done correctly?

It gives you:

• Predictability

• Traceability

• Confidence

• And fewer 2AM “why is the core down?” calls

And that’s the kind of automation we actually want.

👀 In the Extended Version

In the paid version, we go deeper and more practical:

• A real-world CI pipeline example for Ansible

• What Terraform validation should actually check

• How to gate risky diffs (not just syntax errors)

• Firewall rule testing strategies that don’t cause outages

• How to design approval gates that protect prod without slowing engineers to a crawl

• The infra CI/CD maturity model (and how to know where you really are)

• What you absolutely should not automate

If you’ve ever stared at a “green” pipeline and still felt nervous…

The extended version is for you.

Automation isn’t about moving fast.

It’s about moving safely, repeatedly, and without drama.

And in infrastructure…

Drama travels at line rate.

— JJ – Chief Packet Pusher.

Because once you move past definitions, CI/CD immediately collides with:

• Change windows

• Approval boards

• Compliance

• Blast radius

• And people who have PagerDuty scars

This is where most “DevOps blog posts” quietly stop being useful.

Read more

Continuous Delivery does not mean “YOLO deploy to prod on every commit.”

If that were true, most networking and security teams would have already burned the data center down for warmth.

Yet somehow, every CI/CD conversation eventually turns into:

“Wait… are you saying prod deploys automatically now?”

No.
Absolutely not.
Put the pitchfork down.

Continuous Delivery ≠ Continuous Deployment

These two get lumped together like they’re the same thing.

They are not.

Continuous Delivery means:

• Every change is ready to be deployed

• The system could deploy it safely

• Humans still decide when it actually happens

Continuous Deployment means:

• Every approved change goes straight to prod

• No pause

• No human gate

• Maximum stress

Most infrastructure, networking, and security teams want Delivery, not Deployment.

And honestly? That’s the sane choice.

What Continuous Delivery Actually Looks Like

In the real world — not startup demo land — CD usually means:

• Code merges cleanly

• Tests and validation pass

• Config checks don’t scream

• Artifacts are built and ready

• Then it stops

And waits.

For:

• A change window

• An approval

• A human with coffee and context

CD is about readiness, not recklessness.

You’re shortening the distance between “this is ready” and “we approve this.”
Not deleting the approval entirely.

Why Networking & Security Teams Panic Here

Because they’ve seen things.

They’ve lived through:

• “Just one quick firewall change”

• “It worked in the lab”

• “Nothing else should be affected”

• Famous last words, every time

Infrastructure isn’t a stateless web app.

It has:

• Blast radius

• Compliance rules

• Rollback nightmares

• Change tickets that will be audited six months later

CD doesn’t remove those realities.
It just gives you guardrails instead of vibes.

Approval Gates Are Not a Failure

Somewhere along the way, approval gates got labeled as “anti-DevOps.”

That’s nonsense.

Approval gates mean:

• Risk is acknowledged

• Changes are reviewed

• Humans stay accountable

That’s not slowing things down.
That’s not being reckless.

A fast pipeline that pauses before prod is still a fast pipeline.

Rollback Is Still a Human Problem

No matter how clean your pipeline is:

• Rollbacks still need decisions

• Someone still has to say “undo that”

• Context still matters

CD doesn’t magically fix bad changes.
It just makes it easier to not deploy them in the first place.

Which is… kind of the point.

The Real Truth No One Puts on the Slides

Here it is:

Continuous Delivery doesn’t remove humans.
It just makes them faster at approving things.

And that’s a win.

Because the goal was never “no humans.”
The goal was fewer bad surprises.

Want the Real-World Version of This?

The free version explains why Continuous Delivery isn’t the same thing as auto-deploying to prod.

The Extended (paid) version gets into the messy, practical stuff most blog posts skip:

• Where teams intentionally stop automation — and why that’s smart

• What approval gates actually look like in real CI/CD pipelines

• How networking and security teams balance speed with blast radius

• Why “deploy everything automatically” is a terrible default for infrastructure

If you’re responsible for uptime and approvals, the paid version is where this topic actually becomes useful.

— JJ – Chief Packet Pusher

The free version explains what CI is and why people get it wrong.
This version is about how it actually works in the real world — with guardrails, tradeoffs, and mistakes you only make once.

In this issue, we’re getting into:

• What real CI checks look like for infrastructure teams

• Where most pipelines lie to you

• …

Read more

Very few people can explain CI without immediately pointing at a tool and saying,

“It’s basically Jenkins.”

No.
That’s like saying seatbelts are a car model.

Let’s fix that.

What Continuous Integration Actually Is

Continuous Integration is about feedback, not deployments.

CI answers one simple question:

“If I merged this change right now… would something obviously break?”

That’s it.
That’s the whole job.

CI is the boring but critical step where automation taps you on the shoulder and says:

• “Hey, this YAML is invalid.”

• “That variable doesn’t exist.”

• “This config will absolutely brick prod.”

• “Are you sure you meant to do that?”

If CI does its job well, nothing exciting happens.

Which is exactly why people ignore it.

CI Is Not About Shipping Code

Let’s be clear:

• ❌ CI is not deploying anything

• ❌ CI is not restarting services

• ❌ CI is not touching prod

CI is just running checks early so humans don’t have to learn lessons late.

The goal is fast, cheap failure.

Because fixing a typo in a pull request is:

• free

• quiet

• doesn’t involve incident bridges

Fixing it after a reload?

• expensive

• loud

• now you’re explaining it to leadership

What CI Should Be Doing

A sane CI pipeline checks things like:

• Syntax validation

• Linting

• Unit tests

• Schema checks

• Config sanity validation

For infrastructure folks, this looks like:

• Does the playbook parse?

• Does the Terraform plan explode?

• Does the firewall rule reference an object that doesn’t exist?

• Did someone just remove the default route because “it looked unused”?

CI doesn’t need to be smart.
It just needs to be early.

Why Most Orgs Skip CI and Go Straight to Chaos

Because CI is unsexy.

It doesn’t:

• ship features

• make dashboards green in exciting ways

• impress executives

So what happens?

• CI becomes optional

• tests are skipped “just this once”

• pipelines turn into deploy buttons

And now your “CI/CD pipeline” is just:

manual testing + vibes

Which works great until it doesn’t.

CI for Infrastructure (This Is the Important Part)

If you manage servers, networks, or security:

CI is your last line of defense before muscle memory takes over.

CI for infrastructure means:

• catching broken configs before reloads

• validating changes before they touch devices

• stopping “just one quick fix” from becoming an outage

Or, put another way:

CI is how you avoid finding syntax errors via monitoring alerts.

The Dirty Secret of CI

If your CI pipeline fails all the time, people stop trusting it.

If it never fails, it’s probably doing nothing.

Good CI fails just often enough to be annoying
and early enough to be useful.

That’s the balance.

Want the Practical Version? (Paid Subscribers 👀)

The free version explains why CI matters.

The paid version gets into the stuff you actually want to steal:

• What real CI checks look like for Ansible, Terraform, and network configs

• Examples of cheap, fast CI validations that catch breakage without slowing teams down

• How to design CI so it fails early without becoming background noise

• Common “looks fine in CI” traps that still blow up prod — and how to avoid them

Basically:
Less philosophy. More guardrails. Fewer outages.

If you’re tired of finding broken configs after reloads, the paid version is where the real value lives.

👉 Upgrade to get the full breakdown.

Coming Up Next

In Issue 3, we’re tackling the argument that never dies:

Continuous Delivery vs Continuous Deployment

Yes, they’re different.
No, auto-deploying to prod is not required.
And yes, this is where networking and security teams start sweating.

— JJ – Chief Packet Pusher

No buzzwords. No “DevOps journey.”
Just what CI/CD actually looks like when it’s not lying to you.

Read more

“Yeah, we do CI/CD.”

No one asks follow-up questions.
No one wants to know how.
And everyone quietly hopes the pipeline doesn’t break before lunch.

CI/CD has become one of those acronyms—like “cloud-native” or “zero trust”—that people claim because not claiming it feels career-limiting.

The problem?
Most people don’t actually know what it means.
They just know the tools they were handed and the scars they earned.

Let’s fix that.

The One-Sentence Definitions (That No One Uses)

Here’s CI/CD without the buzzwords:

Continuous Integration (CI)
Automatically checking that your changes don’t suck before they get merged.

Continuous Delivery (CD)
Automatically preparing changes so they’re always deployable—even if you choose not to deploy them yet.

That’s it.
No unicorns. No DevOps priesthood. No “digital transformation journey.”

CI finds problems early.
CD removes panic from release day.

Neither one magically makes you “move fast.”

What CI/CD Is Not

Let’s clear the fog:

• It’s not a tool

• It’s not Jenkins

• It’s not GitHub Actions

• It’s not auto-deploying to prod

• It’s not something you buy from a vendor

If you can’t describe your CI/CD process without naming a product, you don’t have CI/CD—you have software.

And software without a process is just an outage waiting to happen.

Why CI/CD Feels Fake in Most Organizations

CI/CD has a reputation problem because this is how it usually goes:

• The pipeline worked in the demo

• Tests check syntax, not reality

• Everything is green… right up until prod explodes

• Infra gets involved after the failure

So the pipeline becomes:

• A checkbox for leadership

• A dashboard that lies

• A thing you bypass “just this once”

At that point, it’s not automation—it’s theater.

The Sysadmin Reframe (This Is the Important Part)

If CI/CD sounds like a dev-only thing, that’s because it’s usually explained badly.

Here’s the infrastructure translation:

CI for infra means:

• Linting configs

• Validating syntax

• Catching bad changes before they touch real devices

CD for infra means:

• Controlled, repeatable releases

• Predictable rollbacks

• Fewer late-night SSH heroics

Or said another way:

CI/CD is just change management that doesn’t hate you back.

It doesn’t remove humans.
It removes surprises.

Why This Matters (Even If You’re Not “Doing DevOps”)

You don’t need microservices.
You don’t need containers.
You don’t need a startup hoodie.

If you manage:

• Firewalls

• Switches

• Servers

• Cloud configs

• Infrastructure-as-code

…you’re already living in CI/CD territory—whether you call it that or not.

The difference is whether your process catches mistakes early or lets them reach production at full speed.

What’s Coming Next

This is the kickoff. Not the deep dive.

In the next issue, we’ll zoom in on the most misunderstood part of the whole thing:

Continuous Integration — why everyone skips it, and why that makes deployments feel cursed.

Paid readers will get real-world examples and practical breakdowns.
Free readers will still get the clarity (and the sarcasm).

Either way, no cult robes required.

— JJ – Chief Packet Pusher

This version answers the question executives ask and engineers fear:

“So… should we move everything to the cloud?”

✅ A Real Cloud Decision Checklist

Move to the cloud only if most of these are true:

• Workloads scale unpredictably

• You deploy of…

Read more

By now, you’ve learned that the cloud is:

• Not magic

• Not cheaper by default

• Not simpler

• And definitely not “set it and forget it”

It’s just someone else’s data center…
with better marketing…
and a bill that updates in real time to shame you.

So the real question isn’t “What is the cloud?”
It’s “Should we actually be using it?”

🤔 When the Cloud Actually Makes Sense

The cloud is great when you need:

• Elastic workloads (spikes, seasonal traffic, unpredictable usage)

• Rapid deployments without waiting on hardware

• Global reach without building your own mini-internets

• Managed services because you’re tired and understaffed

If your environment looks like:

“Sometimes 10 users, sometimes 10,000, nobody knows why”

Congrats — the cloud might save your sanity.

🧱 When On-Prem Is Still King

On-prem still wins when:

• Workloads are predictable

• Latency actually matters

• Compliance teams breathe down your neck

• You already own the hardware

• You don’t want your CFO asking why a test VM costs $800/month

If your setup has:

“The same apps, same users, same traffic… for the last 7 years”

You’re not behind.
You’re just… stable.

🧠 The Big Lie Nobody Tells You

The cloud didn’t remove complexity.

It relocated it.

Instead of:

• VLANs

• Switchports

• Firewalls

You now manage:

• IAM policies

• Service limits

• Inter-service permissions

• Billing alerts

• And permissions that break things silently

Same stress.
New UI.
Higher invoice.

🧾 The Hybrid Reality

Most real environments end up here:

• Some workloads on-prem

• Some in Amazon Web Services

• Some in Microsoft Azure

• One forgotten project in Google Cloud Platform

• And a VPN held together by hope

Hybrid isn’t a failure.
It’s adulthood.

🧠 Final Translation

If this series taught you anything, it’s this:

The cloud didn’t change IT fundamentals.
It changed who you yell at when things break.

The skills still matter.
The concepts still apply.
The buzzwords just got louder.

💡 Paid subscribers get the extended version, including:

• A real decision checklist (cloud vs on-prem vs hybrid)

• Cost-control rules that actually work

• IAM survival strategies

• Migration myths to ignore

• And what not to lift-and-shift unless you enjoy pain

—
JJ – Chief Packet Pusher

Let’s dive deeper.

Read more

This is the final chapter of the beginner series, and oh boy… we saved the worst for last:
Cloud Control Panels — the place where dreams go to 403.

Today we’re decoding three of the cloud’s most chaotic realms:

1. IAM (Identity & Access Management)

2. Billing Dashboards & Cost Visibility

3. Automation & IaC

4. And yes, a final cheat sheet to survive future cloud meetings.

Let’s go.

🔐 IAM: The Final Boss of the Cloud

IAM is the part of the cloud designed to teach humility.

On-prem, access is simple:

• Add the user to the right AD group.

• Log them out.

• Log them in.

• Boom. Done.

Cloud IAM:
“No.”
“No, but with JSON.”
“No, but you almost had it.”
“No, but now the whole environment is broken.”

Every provider has their own special flavor:

• AWS IAM: A choose-your-own-adventure book where every wrong choice returns a 403.

• Azure RBAC: Permission inheritance logic crafted in a labyrinth by Microsoft Minotaurs.

• GCP IAM: Actually the easiest… but still somehow confusing because Google names roles like Pokémon evolutions.

On-prem equivalent:
It’s AD, but every OU is a grenade.

💸 Billing Dashboards: Where Happiness Is a Line Graph

Cloud sales pitch: “Pay for what you use!”
Reality: “Pay for what you used, what you might use, what someone clicked once, and also for that egress you didn’t notice.”

Billing dashboards aren’t dashboards — they’re escape rooms.
You must solve puzzles like:

• “Why did my bill triple overnight?”

• “Who spun up a 128-CPU instance for five minutes?”

• “Why is data leaving my bucket… where is it going… WHO IS PAYING FOR THIS?!”

Welcome to FinOps Lite™, the free trial nobody asked for.

On-prem equivalent:
Your CFO yelling about the power bill every July.

🤖 Automation & IaC: How Adults Use the Cloud

Eventually you will get tired of clicking around the control panel like it’s Minesweeper.
Enter:

• Terraform — “What if config files could ruin prod globally?”

• CloudFormation — For people who think YAML isn’t painful enough yet.

• Ansible — The good friend who buys you coffee and says, “Let’s automate that disaster before it happens again.”

IaC exists for one main reason:
Cloud GUIs were designed by gremlins.

🧭 The Cheat Sheet: What to Google When Lost

Because you will get lost. The cloud control panel likes to rearrange things when you aren’t looking.

Cheat sheet of survival queries:

• “AWS IAM which policy do I need for X”

• “Azure cost explorer why is everything pink”

• “GCP roles viewer vs editor vs why does this exist”

• “Terraform destroy accidentally help panic”

• “Why is my cloud bill so high” (every month)

Congratulations:
If you’ve followed Issues 1–5, you now speak Cloudish, understand the madness, and can hold your own in cloud meetings without sweating through your shirt.

Next step?
Stick around — the Advanced Cloud Decoder series is coming.

— JJ – Chief Packet Pusher