The feeling of touching something fragile: snowflake, IaC and the RPS principle

Every time I have to touch the AWS console, Firebase, or any hyperscaler dashboard directly, the same feeling hits me: I’m handling something fragile. Something I won’t remember how I set up in a few months. Something that, even if I document it with screenshots, I might not be able to reproduce if the interface changes.

That feeling isn’t paranoia. It’s a signal that I’m creating snowflake infrastructure: a unique, irreproducible system that depends on my memory and on specific circumstances that won’t repeat.

In the post on the RPS principle I introduced rock, paper, and scissors as three ways to make technical decisions. This post applies that framework to infrastructure: snowflake as false rock, poorly adopted IaC as false paper, sufficient IaC as genuine paper—and, at a separate extreme, ambitious IaC as scissors.

What is a snowflake

In ops, a snowflake is a server, environment, or configuration so particular that it can’t be reliably reproduced. No two are alike. Each one is unique, like a snowflake.

It’s often associated with the AWS console: years of clickops, manually created resources, security rules that “someone added back in the day” and nobody dares touch. But the problem is broader.

It’s not just the AWS console

Any hyperscaler with a graphical interface can produce snowflakes:

AWS Console — the most famous case.
Firebase / Google Cloud Console — wizards that leave behind a structure that’s hard to replicate step by step.
Azure Portal, Oracle Cloud, and the rest — same pattern: clicks without a versioned source of truth.

If you set up a project in Firebase using the graphical interface and tomorrow you have to rebuild it from scratch, could you reproduce exactly the same structure? The same permissions, rules, auxiliary services? The doubt itself is a symptom.

You don’t need a graphical interface either

Snowflakes don’t require wizards or web panels. SSH into a VPS and install things with apt or dnf, tweak firewalls, edit config files, restart services… until the system works and nobody knows which piece holds up what.

It’s happened to me on virtual machines: so many manual tweaks to firewalls, permissions, or auxiliary services that when something breaks I end up reaching for a backup instead of trying to reproduce the system. Because I don’t trust that I—or anyone on the team—could rebuild it by hand.

In those moments I’ve wished I’d used IaC tools from the start.

False rock

In the RPS principle, rock is conscious pragmatism: solve quickly, assuming the cost of being slightly wrong is low and the decision is reversible.

False rock looks like rock, but isn’t. It’s doing things a certain way because “that’s how it’s always been done” or “that’s what everyone does.” It’s the excess confidence of thinking we’re smarter than we really are: that we’ll perfectly remember that AWS console setup, that screenshots will be enough, that “I’ll document it later.”

False rock accumulates operational technical debt: not the debt of poorly designed code, but the debt of a system that only exists in one specific version, in one specific head, at one specific moment.

It’s not that rock is bad. It’s that we confuse apparent speed with real pragmatism. Genuine rock accepts limitations; false rock ignores them.

A mode of operation, not a type of hosting

In the RPS post I mentioned that VPS, cloud, and bare metal can map to rock, paper, and scissors. But snowflake isn’t a fourth type of infrastructure. It’s a way of managing it:

A VPS can be clean rock (reproducible script, standard base image) or a snowflake (years without rebooting, undocumented artisanal configuration).
Cloud can be paper (IaC, policies, auditing) or a snowflake (console, clicks, “temporary” exceptions that never get removed).

The mistake isn’t choosing VPS or cloud. It’s how you configure it: without a source of truth, without idempotency, without assuming disasters will happen.

Where it matters and where it doesn’t

Not every snowflake is a crime. There are contexts where it makes sense:

Disposable prototypes with a short life and a budget for destruction.
Homelabs meant for experimenting and breaking things — there, fragility can be part of the learning.

But there are contexts where it hurts:

When there’s money at stake — downtime costs, SLAs, customers.
When the system can’t afford to depend on one person — tribal knowledge, vacations, team turnover.
When a disaster requires rebuilding everything from scratch and there’s no manual for dummies or automation that does it without demanding 100% of your attention.

The question isn’t “snowflake yes or no.” It’s “can I afford it in this context?”

IaC in the RPS principle

IaC (Infrastructure as Code) describes infrastructure in versioned files — Terraform, OpenTofu, Pulumi, Ansible — instead of depending on clicks or memory. It’s the natural path out of snowflake territory. But in RPS it isn’t automatically “the right answer.”

False paper: poorly adopted IaC

The symmetric trap to false rock is false paper: it looks like serious engineering, but isn’t. You adopt Terraform or OpenTofu because “it’s the professional thing to do,” but without remote state, without a review workflow, without understanding the declarative model. One person runs apply locally; someone copied the modules months ago and nobody understands them.

You think you’ve left snowflakes behind. In reality you’ve swapped a manual snowflake for a snowflake with .tf files on top: another fragility, with extra complexity in the bargain.

Paper: sufficient IaC

When IaC is done with discipline —versioning, review, shared state, reproducible environments— it becomes genuine paper: you pay upfront work in exchange for stability, predictability, and risk control. You have a manual for dummies — or better yet, a pipeline that brings up the environment without you having to remember every step.

You accept your human limitations: you won’t remember everything in six months, and that’s fine, because the source of truth lives in the repository.

Scissors: ambitious IaC

There’s a third scenario, distinct from false paper and sufficient paper: ambitious IaC by design. Multi-environment, shared modules, policy-as-code, internal platforms, self-managed bare metal. That’s scissors in the RPS sense: maximum long-term potential, more complexity, more risk — but chosen consciously when the context (scale, team, compliance) justifies it. It’s not the natural next step after escaping snowflakes; it’s a different bet.

Tools (a mention, not a tutorial)

I won’t go into detail now — there will be posts for that — but I do want to name the ecosystem:

OpenTofu — open source fork of Terraform, after HashiCorp’s license change. My recommendation as a declarative base.
Terraform — the de facto standard; worth knowing, but today I’d look at OpenTofu first for new projects.
Pulumi — lets you describe infrastructure with imperative languages (TypeScript, Python, Go…). Interesting if you come from manual scripts and struggle with declarative HCL.
Ansible — focused on configuring existing systems; complements OpenTofu/Pulumi well (provisioning + configuration).

All are bridges in the RPS sense: they reduce the cost of recovering later. None is a silver bullet; all require discipline (versioning, review, testing).

Choosing consciously

I’m not writing this to demonize the console or to say everything must be IaC from day one. I’m writing to name the feeling — that fragility when touching something you don’t fully control — and to place it in a framework that helps you decide.

Sometimes false rock is enough: an MVP, a personal environment, a test you’ll throw away tomorrow. Sometimes it isn’t: production, customer data, systems that must outlive your memory.

The skill isn’t in always avoiding snowflakes. It’s in knowing when you’re creating one, what you’re sacrificing, and whether the context allows it. And in accepting that, when it doesn’t, you need a manual for dummies — or the automation that makes one unnecessary.