service-owned-infrastructure

The Team That Builds It Should Deploy It

Every week a service team waits for a central platform team to provision a load balancer, create a DNS record, or update a task definition is a week of velocity lost. The bottleneck is never technical -- it is organizational. When infrastructure lives in a central repository owned by a separate team, every deployment becomes a ticket, every ticket becomes a queue, and every queue becomes a reason to cut corners. Service-owned infrastructure eliminates this bottleneck by placing infrastructure definitions alongside the application code they serve.

This does not mean every team reinvents networking from scratch. It means the platform team provides modules and standards; service teams consume them. The platform team builds the highway. Service teams drive on it.

The Repository Pattern

Each service repository contains its own infrastructure/ directory with per-environment Terraform configurations alongside the application code. This is the foundational layout:

myapp-api/
├── src/                        # Application code
├── Dockerfile                  # Container image definition
├── infrastructure/
│   ├── dev/
│   │   ├── main.tf             # Labels module, remote state references
│   │   ├── service.tf          # Container service definition
│   │   ├── database.tf         # Service-specific database (if needed)
│   │   ├── loadbalancer.tf     # Target groups, listener rules
│   │   ├── registry.tf         # Container registry repository
│   │   ├── secrets.tf          # Secrets Manager entries
│   │   ├── alerts.tf           # Monitoring alarms
│   │   └── backend.tf          # Remote state backend configuration
│   └── prod/
│       └── ...same structure, different values
└── .github/workflows/          # CI/CD pipelines (or .gitlab-ci.yml, etc.)
    ├── ci.yml
    └── cd.yml

The critical insight: application code and infrastructure code are versioned together, reviewed together, and deployed together. When a developer changes the container definition, they update the task definition in the same pull request. When a service needs a new secret, the Secrets Manager entry is added in the same commit that references it.