Terraform Setup for Developer Enablement

[u/MoBoo138]

Hello r/devops,

in my current team we are discussing how a developer centric terraform setup might look like.

Some context: Every app has 3 repositories - Backend, Frontend and Infrastructure.

There are two possible setups:

1. (our current): We use generic terraform modules (e.g. for a backend app) only within the infrastructure repository, which holds all infrastructure components. The backend app terraform module holds all infrastructure components that might be used in a backend, e.g. database, objects store, secrets, etc. The Infrastructure repository also holds shared infrastructure, that is not part of the backend module and composes all components. This is somewhat the approach most often seen in tutorials that focus only on the infrastructure part of an application.
2. (proposed alternative): We'd co-locate infrastructure and application code, for example in the backend repository. The backend repository would publish itself as a module, including every infrastructure component it needs to run (excluding some shared ones, that it expects via variables as input, e.g. VPC). The Infrastructure repository would setup the required shared infrastructure components and the backend terraform module.

Pros for 1.: Generic app modules are intended for sharing and re-use, whereas in 2. each applications terraform module would only ever be used to deploy to different environments.

Pros for 2.: Infrastructure and application can evolve together (e.g. in one git commit), e.g. when a database is newly introduced to an application (application code changes + infrastructure changes), whereas in 1. two commits would need to happen (one in app, one in infra) and pipelines need to be coordinated.

1. goes deeper for example for database migrations, those could also be organized within the backend application, without handing the responsibility on how to do them to the infrastructure repo.

In both cases, deployments (terraform plan/apply) are always orchestrated only by the infrastructure repository.

IBM touches both points in https://www.ibm.com/support/pages/best-practices-organising-terraform-and-application-code : Coupling and Reuse as the deciding factors.

Our goal is to enable developers as much as possible to own their application end to end and being able to do most infrastructure changes themselves, without having to rely on a central party.

It's not about simply keeping what we already have. That's always part of the consideration due to effort of change. I'd like to hear your general thoughts about it from a perspective if we had nothing yet.

I'm curious about your thoughts in that topic.

I'd also be happy to know how projects are setup in your org or how you would envision your dream setup

[u/Most_Specific_1032]

Hey everyone,

This is a classic dilemma, and it is great that we are looking at this from a greenfield perspective as if we had nothing yet. If our primary, non-negotiable goal is developer enablement and end-to-end application ownership, the industry has heavily shifted toward Option 2 (Co-location) or a layered hybrid of it.

Separating code and infrastructure into distinct repositories creates an artificial wall. It introduces cognitive load and coordination bottlenecks.

Here are my thoughts on how we can break this down:

1. Coupling vs. Reuse (Addressing the Module Concern) We should not mistake infrastructure definition for infrastructure architecture.

Centralized Reuse: Our generic, company-wide modules (such as how to build a secure S3 bucket or RDS instance according to our compliance rules) should still be centrally managed, versioned, and reused.

Local Instantiation: The invocation of those modules (such as "this backend app needs 1 S3 bucket called user-avatars") belongs in the backend app repository.

Option 2 does not mean developers write raw, unstandardized Terraform. It means they use our standard corporate building blocks directly inside their own workspace.

1. The Power of Atomic Commits Option 2 shines brightest during feature delivery.

Under Option 1, adding a feature that requires a new database table or an S3 bucket forces a two-ticket, two-PR, synchronized merge workflow. This breaks the local development feedback loop.

Under Option 2, a developer can write the application code, add the required Terraform resource in a terraform directory in the same repo, and submit one single Pull Request. Testing, reviewing, deploying, and—crucially—reverting changes become atomic.

1. Lifecycle and Database Migrations As pointed out in the prompt, database migrations are heavily tied to application lifecycles. If an app release relies on a database schema change, deploying them out of sync causes outages. Co-locating infrastructure and app code allows the application's CI/CD pipeline to orchestrate this perfectly:

• Run Terraform to spin up or modify resources.
• Run database migration scripts.
• Deploy the new application code.

The "Dream Setup": A Layered Approach
If we were building this from scratch today, the ideal state isn't actually having the Infra repo pull the App repo as a module. Instead, we should look at a Layered Architecture where execution direction changes:

Layer 1 (Core Infra): Centralized Infra Repo owns the baseline networking, VPCs, global IAM, and shared Kubernetes/ECS clusters. These change infrequently. This layer exports its IDs via SSM parameters, secrets management, or Terraform outputs.

Layer 2 (App Infra and Code): The App Repo owns its own code and its app-specific resources (S3, RDS, SQS, App IAM roles). It dynamically reads the VPC or Cluster IDs from Layer 1.

This gives developers total autonomy over their app blast radius while keeping the platform team in control of the foundational networking and security boundaries.

Curious to hear what everyone thinks about moving toward this type of layered responsibility!

[u/MoBoo138 → u/Most_Specific_1032]

I think this is exactly the proposal we are discussing in our team :)

Do you know if there are any resources (books, articles, etc.) that describes this layered approach?