N100FN100F
Published on

State: the infrastructure's memory

Between the code and the real infrastructure there is a third piece almost nobody sees until it fails: the state. Where it is kept, who can write to it and how it is protected decides whether infrastructure as code is safe or a risk.

Service line Automation and IaC

The invisible piece

When an infrastructure-as-code tool creates a server, it notes somewhere that 'this server in the code corresponds to this real resource, with this identifier'. That record is the state. Thanks to it, next time it knows what already exists, what changed and what it has to create or delete.

While everything works, nobody thinks about it. When it is lost, corrupted or modified by two people at once, the tool stops knowing what is its own, and the consequences range from duplicates to deletions nobody asked for.

The memory between code and realityCode, state and reality, with the five rules for protecting the state.IAC · STATEThe memory between code and realitythe tool compares Codewhat you want Realitywhat exists Statewhat the tool believesRemotenever on a laptopWith lockingone change at a timeWith versionsyou can go backEncryptedtreated as a secretSplitby environment and area lockN100F · n100f.com

Rules for the state

Never on a laptop. The state lives in shared, remote storage, not on the machine of whoever ran the last change.

With locking. While somebody is applying a change, nobody else can. Two simultaneous changes against the same state are the classic recipe for corrupting it.

With versions. Every change to the state keeps a copy of the previous version. If something goes wrong, you can go back.

Encrypted and with restricted access. The state can contain sensitive data (addresses, identifiers, sometimes values the provider returns). It is treated as one more secret.

Split by scope. One giant state for the whole organisation makes every change slow and risky. The healthy approach is to separate by environment and by area (network, data, applications), so that a mistake in one does not reach the others.

Nobody edits it by hand

The state is modified only through the tool. Editing it by hand to 'fix' something is like changing the accounting ledger to make it balance: the problem is hidden, not resolved. If the state and reality disagree, you investigate why and correct it with the commands provided for that.

With the state under control, the next problem is one of scale: how to describe twenty environments without copying the same code twenty times.

How we apply it: Automation and IaC.

If your cloud cost keeps growing and nobody knows why, or your architecture depends on whoever built it, let’s talk.

Let’s talk