What Is Infrastructure as Code? And Why I Stopped Managing Infrastructure Manually

There is something I've found quite interesting over the years.

As software engineers, we've spent decades refining the way we build software.

Whenever we want to introduce a new feature, we usually follow a well-defined workflow.

• Create a new branch.
• Write the code.
• Commit the changes.
• Push to Git.
• Open a Pull Request.
• Get the code reviewed.
• Merge.
• Let CI/CD build and deploy everything.

Every change has a history.

Every change is reviewed.

If something goes wrong, we know exactly who changed what, when it happened, and how to roll it back.

For most engineering teams today, that's simply how software development works.

But there was one question I had never really asked myself during the early years of my career.

If application code is treated as source code, why isn't infrastructure?

One ordinary day...

Imagine receiving a seemingly simple task.

"Can you create a new staging environment that matches production?"

Sounds straightforward.

You open the AWS Console.

Or Azure Portal.

Or Google Cloud Console.

Or Vercel Dashboard.

Or Firebase Console.

Then you start creating resources one by one.

• A Virtual Machine.
• A PostgreSQL database.
• A Storage Bucket.
• A VPC.
• A few Security Rules.
• Some DNS records.
• Several Environment Variables.

About an hour later, everything is up and running.

You verify the deployment.

The application works.

Task completed.

Two weeks later.

A production bug suddenly appears.

The team spends hours investigating.

Eventually, the root cause isn't the application.

It isn't the database.

It turns out Production has a different infrastructure configuration than Staging.

Maybe it's:

• An extra firewall rule.
• A different environment variable.
• An IAM permission.
• A database configuration flag.

The most frustrating part?

Nobody knows when those differences were introduced.

There was no commit.

No Pull Request.

No code review.

No changelog.

Just a familiar sentence that almost every engineering team has heard at least once.

"I think I changed something in the dashboard the other day..."

If you've worked with cloud platforms like AWS, Azure, GCP, Firebase, or Vercel, chances are you've experienced something similar.

I certainly have.

Not because someone made a mistake.

But because cloud dashboards were never designed to become the source of truth for your infrastructure.

Dashboards are not the problem

Before going any further, I'd like to clarify something.

This article is not about criticizing cloud dashboards.

In fact, I still use them every single day.

They're incredibly useful for:

• Monitoring infrastructure.
• Investigating incidents.
• Reading logs.
• Viewing metrics.
• Inspecting resources.
• Debugging production issues.

Dashboards are excellent tools for observing infrastructure.

But they're not the best tools for managing it.

Those two responsibilities sound similar, but they're fundamentally different.

For example, a dashboard can tell you:

• Which region your database is running in.
• How much CPU it's consuming.
• How many active connections it has.
• Whether backups are currently enabled.

What it usually can't answer is:

• Why was this database configured this way?
• Who changed this configuration?
• What was the previous configuration?
• Was this change reviewed?
• Can we reproduce this exact environment somewhere else?

Those are the questions that become increasingly important as systems grow.

The more projects you have...

The more environments you maintain...

The more engineers join your team...

The harder those questions become to answer.

We've already solved this problem for software

When you think about modern software engineering, almost everything revolves around one simple idea.

Source code is the Single Source of Truth.

Nobody logs into a production server and edits Java or Node.js files directly.

Nobody manually patches source code on a running application and calls it a deployment.

Every change begins with source code.

Then goes through Git.

Then a Pull Request.

Then a review.

Then CI/CD.

So why should infrastructure be any different?

Why do we treat application code as a first-class engineering asset while managing infrastructure through manual operations?

That question eventually led me to Infrastructure as Code.

And it's also where this entire series begins.

What Infrastructure as Code Really Means

If this is your first time learning about Infrastructure as Code, you've probably seen a definition similar to this.

Infrastructure is managed and provisioned through machine-readable configuration files instead of manual processes or interactive configuration tools.

It's technically correct.

But I don't think it captures what makes Infrastructure as Code truly valuable.

After working with Terraform and Terragrunt for several years, I've come to believe that Infrastructure as Code has never really been about writing code to create servers or databases.

That's merely the outcome.

The real value lies in changing the way we manage infrastructure.

From ClickOps to GitOps

There is a term that often comes up in the DevOps community.

ClickOps

It's an informal way of describing infrastructure management through web dashboards.

Need to increase CPU for a virtual machine?

Log in.

Select the VM.

Change the configuration.

Click Save.

Need another storage bucket?

Open the dashboard.

Click Create.

Need to add an environment variable?

Open the settings page.

Click Save.

Fast?

Absolutely.

At least for the first few times.

But imagine doing that for:

• Ten different projects.
• Four environments.
• Multiple cloud providers.
• A growing engineering team.

Sooner or later, someone will ask a very simple question.

"How exactly was our infrastructure built?"

If the answer is:

"Let's open the dashboard and figure it out."

Then maintaining that infrastructure is already becoming difficult.

Infrastructure as Code changes this completely.

Instead of treating the dashboard as the place where infrastructure is created, it becomes a place where infrastructure is observed.

Every change starts from source code.

Just like application development.

Developer
 
    │
 
    ▼
 
Infrastructure Code
 
    │
 
    ▼
 
Git Repository
 
    │
 
    ▼
 
Pull Request
 
    │
 
    ▼
 
Code Review
 
    │
 
    ▼
 
CI/CD
 
    │
 
    ▼
 
Cloud Infrastructure

That's why many engineers describe Infrastructure as Code as a way of working, not just another tool.

And I completely agree.

Infrastructure deserves its own Single Source of Truth

One of the most important principles in software engineering is having a Single Source of Truth.

For applications, that's your source code.

If production behaves differently from what's in the repository, we consider it a problem.

Infrastructure should follow the same principle.

The source of truth shouldn't be:

• A cloud dashboard.
• A Wiki page.
• An Excel spreadsheet.
• Internal documentation.
• Or the memory of your senior engineer.

It should be your infrastructure code stored in Git.

That means if someone asks:

"How many Redis instances does production have?"

You don't log into AWS.

You open the repository.

If someone asks:

"When did we enable database backups?"

You don't ask around.

You check Git history.

If you need another production-like environment, you don't follow a twenty-page deployment guide.

You simply run the infrastructure code again.

That's the real power of Infrastructure as Code.

Infrastructure as Code is not Terraform

When I first started learning DevOps, I had a very simple assumption.

Learning Infrastructure as Code means learning Terraform.

Looking back, that's like saying:

"Learning programming means learning Java."

It's not wrong.

But it's incomplete.

Terraform is one implementation of Infrastructure as Code.

Infrastructure as Code is the idea.

Terraform is the tool.

Just like Git is an implementation of Version Control, Terraform is an implementation of Infrastructure as Code.

Today there are many different tools that embrace the same philosophy.

Throughout this series, however, I'll focus on Terraform and Terragrunt.

Not because they're the only options.

But because they're the tools I use every day to build and manage real-world infrastructure, including the very blog you're reading right now.

This series isn't about memorizing Terraform syntax.

It's about understanding the engineering mindset behind Infrastructure as Code and applying it to production systems.

What's next?

So far, we've answered one important question.

Why does Infrastructure as Code exist?

But another question is even more interesting.

How does Terraform actually work?

Terraform doesn't execute line by line like a shell script.

It doesn't simply read configuration files and create resources.

Instead, it follows a completely different execution model.

Understanding that model is, in my opinion, the single most important step to mastering Terraform.

And that's exactly where we'll begin in the next article.