Skip to content
back to achievements

Case study · LookSuite

Client project · AugmentProject period2025 – Present

Infrastructure as code

Established Terraform-managed infrastructure and Docker-based service workflows to support consistent development and production delivery.

01

Why

The platform needed several environments: numbered sandboxes, QA, staging, production and a disaster-recovery copy. Building each one by hand in the GCP console means repeating the same setup and risking each copy drifting from the others. Docker was the default for every project I build, so containerizing the services was not a separate decision.

02

Decision

  • One reusable environment, many instances. There is one Terraform root for an environment. Sandbox, QA, staging, production and DR are the same code with different input variables and a separate HCP Terraform workspace each. Switching environment means changing the workspace and the variable file, with no copied folders and no edits to the modules.
  • Shared things kept apart. The few things that must survive an environment being destroyed (the accounts that run automation, trust between workspaces, parent DNS delegation) are managed separately from the environment itself. Destroying a sandbox never touches them, and no resource is managed in both places.
  • Start from what already existed. I exported the live, hand-built environment with Terraformer and used it as the reference for the topology. I refactored it into clean modules by domain (networking, IAM, data, compute, observability) and kept an adoption log mapping old addresses to new ones, so importing the live environment caused minimal drift.
  • Safety by design. Destroying an environment needs an explicit confirmation naming that environment, only the numbered sandboxes can be destroyed, production destroy is blocked, and the shared accounts are deletion-protected. State locking stays on. A plan with an unapproved replacement or deletion is not applied.
  • Naming and labels. Resource names derive from the environment name and a prefix, and a fixed label set goes on every resource that supports labels.
  • Secrets. They live in Secret Manager and are created by Terraform where possible. A rotation runbook records which secrets Terraform generates, which services must restart or redeploy, and how to prove each service picked up the new value.
  • Docker runs the same containers for local development and production.

How it fits

Hover or focus a box for the story behind it.

One reusable Terraform root creates every environment, each with its own variable file and workspace. The shared accounts live apart from the environments, and destroying one needs an explicit confirmation.One code, many environmentsShared parts kept apartDestroying an environmentOwn variables and workspaceNever touchesOne reusable Terraform root. Sandbox, QA, staging, production and DR are all the same code.Terraform root One reusable rootThe numbered sandboxes. They are the only environments that can be destroyed.Sandboxes Numbered, disposableSame code, with its own variable file and its own HCP Terraform workspace.QA Same codeSame code, with its own variable file and its own HCP Terraform workspace.Staging Same codeProduction destroy stays blocked during ordinary operation.Production Destroy is blockedA copy of production's topology, so production can be recreated.Disaster recovery Production topologyAn environment can be destroyed and recreated from the same code.Environment DestroyedShared automation accounts, trust between workspaces and parent DNS delegation. Managed separately and deletion-protected.Control plane Untouched, protectedSomeone asks to destroy an environment.Destroy request Names the environmentAn explicit confirmation that names the environment has to match the selected state and workspace.Confirmation Must match exactlyOnly the numbered sandboxes can be destroyed.Sandbox Can be destroyedProduction destroy is blocked during ordinary operation.Production Blocked

One reusable Terraform root creates every environment. Switching environment means changing the workspace and the variable file, with no copied folders and no edits to the modules.

03

Alternatives considered

No tools were compared. The one deliberate choice was against a copied Terraform root per environment, because copies drift. I made it a hard rule that there is one reusable root.

04

What I built

Developed and maintained infrastructure configuration using Terraform to define and manage application infrastructure.

Containerized application services with Docker and established container-based workflows supporting both local development and production environments.

This provided a more consistent environment across development and deployment workflows while allowing infrastructure configuration to be maintained as code.

05

Trade-offs

  • Keeping the shared accounts separate from the environments means deciding, for every resource, which side owns it.
  • The strict confirmations make a destroy deliberate and slower, which is intended.

06

Outcome

An environment is created, destroyed and recreated from the same code with a different variable file. Production topology can be reproduced for disaster recovery, and the shared accounts survive an environment teardown.

Technologies