← Lab Runs in your browser
The same three things, built twice
A network, a firewall rule that needs it, and a server that needs both. Build it by hand below, then run your own notes again. Then describe what you want instead, and run that twice too.
What goes wrong
Three things, and one depends on the last: a network, a firewall rule that needs the network, and a server that needs both. Doing this by hand means remembering that order — today, and again in six months when something needs rebuilding and the order is no longer obvious.
The bigger problem shows up on the second run. Notes that worked once don't mean much if running them again just errors out on "already exists" — or worse, quietly creates a second copy of something you already had.
Run it
Same three things, two ways. On the left, three buttons and no memory of what you already did. On the right, one file saying what should exist, applied twice — and once more after something changes behind its back.
By hand
Click these in the order that makes sense to you.
Declared
What should exist, written once.
network "main" {}
firewall "web" {
network = main
allow = [80, 443]
}
server "app" {
network = main
firewall = web
}What this doesn't prove
This is three toy resources kept in a JavaScript object — no API calls, no state file, no real network or firewall anywhere. What it keeps honest is the mechanism: a real tool like Terraform or the CDK works out the order from what each resource refers to, compares what exists against what you asked for, and only touches what's actually changed. That part isn't simplified, just shrunk from the hundred resources a real setup has down to three.
Where this came from
At RWE the delivery setup already worked this way — AKS underneath, with Helm and Terraform managing it. I didn't own that layer; I worked with it when a change reached down into it. This is the part that stuck: the difference between a script you hope still works and a description of what should exist that a tool can check against reality.