Infrastructure as Code
The write → plan → apply → state loop, remote state with locking, and a Terraform module that provisions the GPU node pool your inference service runs on.
Click-Ops Doesn't Scale, and It Doesn't Remember
If your GPU node pool exists because someone clicked through a console one afternoon, you have a problem you cannot see yet. There is no record of why it is configured the way it is, no review of changes, and no way to recreate it if it disappears. Infrastructure as code replaces the console with a file: your infrastructure is declared in version-controlled HCL, changed through pull requests, and reconciled by a deterministic loop.
The discipline maps cleanly onto how Knox already runs everything else — every code change to Mission Control or a trading bot is a reviewed commit, never a hand-edit on the running box. Infrastructure earns the same rule.
The Loop Is the Discipline
Five steps, then a loop back to the start. You write desired state in HCL. You init to pull providers and configure the backend. You plan to see the diff between your code and reality. You apply to execute that diff against real provider APIs. The result is recorded in state, which the next plan diffs against. Drift or a new requirement sends you back to write — as a PR, never a console edit. That closing loop is GitOps, and it is the whole point: humans never touch the infrastructure directly.
State Is the Database; the Lock Is the Transaction
Terraform's state file is the map between your declared resources and the real-world IDs they correspond to. It is the source of truth for what exists. Where that file lives decides whether your infrastructure belongs to a team or to one person's laptop.
Remote state — terraform.tfstate in an S3 bucket, versioned and encrypted — makes the infrastructure shareable: any operator or CI pipeline reads the same truth. The lock makes concurrent access safe: two applies cannot race on the same state and corrupt it. One acquires the lock and proceeds; the other waits. You need both. (A currency note: Terraform 1.10+ can lock natively in the S3 backend with use_lockfile = true, and DynamoDB-based locking is the legacy path being deprecated from 1.11 on. The DynamoDB table with a conditional write is still the pattern you will see across existing stacks, so know both — but reach for native S3 locking on anything new.) Local state on a single laptop is the single point of failure that turns a team's infrastructure into one person's undocumented secret.
Authoring a Module
The unit of reuse in Terraform is the module: a parameterized bundle of resources with variables (inputs) and outputs (values other code consumes). A GPU node pool is a perfect candidate — you want to provision it the same way every time, varying only the machine type and count.
What's Next
Your inference service is now served (485), grounded (486), cost-controlled (487), and reproducibly provisioned (this lesson). The track turns next to keeping it healthy: The next lesson covers observability — the three pillars (metrics, logs, traces) and the Prometheus scrape model that proves your service is actually doing work, not merely running.