Describe the ground first | Beacon infrastructure

Step 01 of 06

Learn the concept

A console click is fast until nobody remembers which box was clicked, in which region, under which account. The first outage after that is archaeology with billing attached. Infrastructure as code turns that fog into a reviewed change with a diff, an owner and a rollback story.

Both paths can create a working server. Only one can explain itself six months later, when the subnet is full and the person who clicked it has joined a startup selling observability to observability companies.

Step 01

The ideas this is made of

Desired state beats remembered procedure

A runbook says what a human should do. Desired state says what must exist. Terraform then compares that declaration with real cloud resources and proposes changes. This resembles Kubernetes reconciliation, but the objects are VPCs, keys and instances instead of Pods. The file becomes the durable source of intent; the provider performs the translation into API calls.

Idempotence is the promise behind safe reruns

An idempotent operation can be repeated without changing the result after the first success. mkdir -p is idempotent; echo line >> file is not. IaC tools aim for idempotence by recording identity and comparing attributes before acting. That is why a good second run says there are zero changes instead of creating a second VPC with the same name.

Pets become incidents when nobody can rebuild them

A pet server is patched, tweaked and named by hand. It may be beloved; it is also unreproducible. Cattle is not cruelty. It means the important thing is the definition, not the individual machine. If an instance dies, the replacement is created from the same inputs. The humane part is that nobody has to SSH in at 03:12 to remember which package was installed.

IaC makes change review concrete

A pull request can show that a database moved from private to public, a security group opened port 22 to the world, or a node size doubled. That diff is searchable later. It is also reviewable before money is spent. Console changes can be logged, but logs say what happened after the fact. A plan says what will happen while there is still time to stop it.

The tool cannot remove judgement

IaC can faithfully create a terrible design. It will not know that a CIDR is too small, that NAT costs are inappropriate, or that a secret slipped into state. Cloud APIs also return eventually consistent answers. Treat Terraform as a careful operator with a ledger, not as architecture in a box. You still own the blast radius.

Desired state without the cloud

mkdir -p deploy/infra
cat > deploy/infra/intent.txt <<'TXT'
beacon needs one private network, one small host, and a destroy plan.
TXT
cat deploy/infra/intent.txt

The example is deliberately plain. The value is not the text file; it is the habit of writing intent before touching infrastructure. Terraform gives that habit a provider protocol, a graph and a state file.

Manual change versus declared change

Question	Console change	IaC change
Who approved it?	Maybe a ticket	The pull request
Can it repeat?	Only if remembered	Yes, from files
Can it drift?	Silently	Plan can reveal it
Failure mode	Snowflake server	Bad code, reviewed
Audit trail	Provider logs	Git plus provider logs

What these are called on the job

Declarative — Describes the desired end state, not the step-by-step procedure used to reach it.
Drift — A difference between configuration, Terraform state and the real resource now returned by the provider API.
Snowflake — A unique server or environment that cannot be recreated because its important changes were manual.
Reconciliation — The loop that compares desired and observed state, then acts to reduce the difference.