Dealing with Fragmented Terraform Repositories Across Teams: Is It Common?

Having shared resources like you described is pretty common, and the key is to manage what your app requires efficiently. Ideally, keep all necessary resources for your application in one place—treat the shared resources as external dependencies but change them locally when feasible. However, be cautious about making changes that fall under the purview of the main infrastructure team's responsibilities.

Yep, dealing with different repos for shared resources is a normal headache in a growing organization. You've got a couple of options: either roll with the punches or implement a management layer, like a control plane or Internal Developer Portal, to streamline access and governance over the repos.

In my experience, we handle shared modules in various ways—sometimes they have their own repo, and other times they're included in our main infrastructure repo. For example, we have a dedicated repo for ECR modules but keep our EKS stuff in the infrastructure repo. It helps to have a team that solely owns that infra, while we collaborate when necessary. Right now, we're using Terraform Cloud as our control plane but looking into alternatives. As for context switching, I've found using VS Code with a single workspace that pulls in all relevant repos to be super helpful!

Consider using something like Artifactory for managing images related to your shared components. You could tag your Postgres and Kafka images so you can reference specific versions without the hassle of automatic updates every time a new release comes out.