Leveling Up Infrastructure Configuration with Terraform: What We Learned from “Raising Infrastructure Configuration to the next Level” by Johannes Brottrager (durchblicker.at)

Context and stakes

durchblicker.at is Austria’s largest comparison website, handling around 15,000 comparisons per day across insurance, energy, banking, and more. In the talk “Raising Infrastructure Configuration to the next Level,” Johannes Brottrager, a full‑stack developer at durchblicker.at, describes how the team evolved from a scattered, manually maintained server fleet to a declarative, versioned infrastructure practice centered on Terraform and managed container environments.

It’s not a Terraform 101. Instead, it’s a compact tour of the problems a growing company hits, the patterns that worked, and the practical gotchas teams should anticipate.

This recap extracts the concrete architecture moves and lessons that are most actionable for engineering teams.

The starting point: many clouds, procedural setup, little consistency

As a startup becomes a scale‑up and then an established company, infrastructure tends to mirror that growth. durchblicker.at had the familiar symptoms:

• A mix of providers: AWS, GCP, DigitalOcean, Azure, Hetzner — plus a bare‑metal server in the office. This variety can be great for experiments but becomes hard to keep consistent and secure at scale.
• A procedural orchestration mindset: Much was managed with Ansible — powerful for SSH‑based configuration but still imperative. You describe how to get there, not what the desired end state is. Over time, this increases drift and cognitive load.
• Inconsistent testing environments: Without strict versioning of configurations, people could “just change something” on test systems. The next person faced surprises and mismatches.
• Update overhead: Keeping operating systems and packages up to date across numerous servers was heavy work with security implications.

The common denominator: Too many moving parts, too little declarative control, and not enough reproducibility.

The pivot: harmonize providers, use managed containers, embrace Terraform

The team’s path to a solution had three core elements.

1) Harmonize providers

• durchblicker.at consolidated primarily on GCP. Fewer providers meant fewer integration seams and a cleaner operational model.

2) Managed container environments

• Rather than maintaining servers everywhere, the team leaned on managed container runtimes. Johannes used Cloud Run as the example in the talk: You deploy a container image, Cloud Run scales it up and down, and you avoid heavy OS maintenance.

3) Infrastructure as Code with Terraform

• Declarative definitions: Instead of scripts describing steps, Terraform config describes the desired resources and parameters. Terraform figures out the plan and applies it.
• Versioning: Infrastructure lives in text files in version control, keeping changes visible and auditable.
• Multi‑cloud support: Terraform supports all major providers, which enables migration strategies or multi‑cloud setups without tooling churn.
• Change workflow: Edit parameters, review the plan, apply. As Johannes put it: run terraform apply, and the change takes effect across the defined resources.

A readable “Hello World,” no script archaeology required

Johannes sketched a minimal Cloud Run service: a resource definition with type, name, and location; a template pointing at a container image; CPU and memory limits (e.g., 1 CPU, 512 MB RAM); and 100% traffic routed to the instance. The point wasn’t the snippet itself but the clarity: Anyone seeing the resource understands what will be deployed, without digging through shell scripts.

Avoiding copy‑paste across environments: modules plus a runtime config switch

Running Dev, Staging, and Production without duplicating everything is the classic IaC challenge. durchblicker.at addressed this with Terraform modules and a simple but powerful runtime switch.

Modules as reusable building blocks

• A shared module encapsulates the Cloud Run application. It exposes parameters such as min/max scale, memory, and CPU throttling. Each environment can set sensible values without re‑creating the entire resource definition.

“config file location” as the environment selector

• Configuration belongs with the application code. Through Terraform, the team injects an environment variable that tells the service which config to load: prod, staging, or dev.
• On startup, the app reads this variable and chooses the right configuration file. One build artefact, multiple environments — and the toggle is explicit, declarative, and versioned.

Secrets done right: placeholders and Secret Manager at startup

Teams often avoid versioning configuration because of secrets, which then ruins reproducibility. durchblicker.at’s approach keeps both security and version control intact.

The previous situation

• Config files lived only on servers to avoid committing secrets. No versioning, no traceability, fragile test environments.

The new pattern: placeholders + Google Cloud Secret Manager

• Config files contain placeholders for sensitive values — think secret::NAME.
• On startup, the container selects the appropriate environment config (prod/staging/dev), parses the file, and replaces each secret placeholder by fetching the value from Google Cloud Secret Manager.
• Permissions are explicit: In Terraform, the team defines which Cloud Run services can access which secrets — minimal access on a need‑to‑know basis.
• Secrets are environment‑scoped: Production secrets differ from staging and development, without branching artefacts.
• Environment variables can also be filled from secrets declaratively: Terraform references the secret key; at runtime, the value is injected securely.

This solves the balance: Configuration stays versioned and transparent; secrets remain centralized, access‑controlled, and out of the repository.

Terraform’s practical gotchas (and how to work with them)

Terraform isn’t magic — it applies the declared state. Johannes highlighted a few real‑world concerns and remedies.

1) Parallel work, state, and locking

• A Terraform configuration typically covers a complete project. If two people add resources in parallel and each applies from their local perspective, the one without the other’s changes is effectively telling Terraform to remove those unfamiliar resources.
• State lock: Terraform locks the state during an apply so that concurrent applies don’t step on each other. That avoids race conditions but doesn’t solve divergent local states.
• Practical habits: Coordinate changes, push and pull early, and use separate test environments when trying new things. With IaC, test environments become easy to spin up and tear down.
• Branch caution: Branches that define radically different infrastructures are risky. An apply on the “wrong” branch will reshape live infrastructure accordingly. It’s as much a process issue as a tooling one.

2) Renaming resources causes destroy/recreate — unless you use move

• In Terraform, a resource’s identifier in the state is tied to its name in the config. A naive rename triggers a destroy/create cycle.
• The remedy exists: the move command. Use it to migrate a resource to a new address in state without destruction. Johannes’ take: learn this early; it saves painful surprises.

3) Gaps for fresh cloud features

• Provider implementations sometimes lag behind new cloud features. Johannes mentioned an example where automatic compression for backend buckets wasn’t yet implemented. Workarounds exist, but teams should plan for such gaps when aiming at cutting‑edge features.

Actionable steps for engineering teams

Distilling the talk’s patterns yields a pragmatic checklist that maps directly to what durchblicker.at implemented.

• Reduce provider sprawl
• Consolidate where possible. durchblicker.at focused on GCP, which simplified operations and Terraform usage.
• Prefer managed container environments
• Offload OS maintenance. Cloud Run is a natural destination for containerized services that benefit from autoscaling and minimized ops overhead.
• Embrace declarative, versioned infrastructure
• Terraform as the single source of truth. Text files in version control, plans for review, applies for reproducible changes.
• Use modules for reuse and consistency
• One module per service type, with parameters for min/max scale, memory, and CPU. Keep Dev/Staging/Prod consistent but tunable.
• Keep config with the application code; select the environment at runtime
• One build for multiple environments. Terraform sets a „config file location“ variable; the app loads the right file at startup.
• Handle secrets via placeholders and a secret manager
• Never commit secrets. Placeholders in config files, secure resolution at startup from Secret Manager, and IAM‑controlled access defined in Terraform.
• Respect state and coordinate applies
• Understand state locks; coordinate parallel changes; use separate test environments for experimentation. Be careful with branches that materially change infrastructure.
• Name resources thoughtfully; use move for renames
• Avoid accidental destroy/recreate cycles. The move command should be part of the team’s standard playbook.
• Anticipate provider feature gaps
• When you need a brand‑new cloud feature, check if the provider supports it; if not, plan a workaround.

Why this pays off

With provider harmonization, managed containers, and Terraform, durchblicker.at achieved the trifecta that growth‑stage teams need most: clarity, reproducibility, and control.

• Transparency: The full infrastructure is visible in files. Reviews and audits are straightforward.
• Reproducibility: Dev, staging, and prod can be brought up consistently. Test environments are easy to provision without hand‑tuned mysteries.
• Security without sacrificing versioning: Secrets live in Secret Manager, while configuration files remain in version control. IAM governs who can read what.
• Operational ergonomics: Scaling limits and memory are declarative per environment. You tweak a parameter, not a fragile script.

Johannes’ closing sentiment captures it concisely:

Closing thoughts: A grounded path from entropy to order

“Raising Infrastructure Configuration to the next Level” is a practical field report. It describes a route any team with a patchwork of servers and inconsistent test systems can follow:

• Consolidate your platform where you can.
• Lean on managed container runtimes.
• Move to declarative infrastructure with Terraform, use modules, and manage state carefully.
• Keep configuration with your code, and resolve secrets securely at startup from a secret manager.

The details that Johannes chose to emphasize — from state locks and branch caveats to the move command and provider gaps — are exactly the things that make or break day‑to‑day IaC adoption. If your infrastructure story resembles durchblicker.at’s starting point, this talk provides a clear and realistic blueprint for leveling up.

• 

  

  Out of the Dark, Into the Light

  Michael Karner von Durchblicker erzählt in seinem devjobs.at TechTalk über den Weg, wie das Team die gesamte Infrastruktur auf die Google Cloud Platform gewechselt hat – und welche Überraschungen es dabei gegeben hat.

  Watch now

• 

  

  Andreas Deuschl, CTO von Durchblicker

  Der CTO von Durchblicker Andreas Deuschl gibt im Interview Einblicke in die Organisation des Devteams, wie das Recruiting und Onboarding abläuft und welche Technologien eingesetzt werden.

  Watch now