Thanks for the response @Dennis .
Note 1: I have zero knowledge of what IaC is or what it looks like.
FYI It’s code that defines what infrastructure to create and how to configure those resources using a desired state process. In short it means you don’t manually create resources in cloud provider portals but instead use a CI/CD processes for adding quality to the infrastructure configuration. Example products supporting this are ARM (Azure Resource Management) templates, Terraform, and Pulumi.
First of all, I have the feeling that you say “Which AC owns something?” but they don’t own anything. The logical service is the owner of something, because that’s where the boundaries are.
I don’t think I actually said the AC owns the resources and only meant that the service does, and by service I mean the logical business service. The ACs only make use of the resources owned by the service. Sorry if I confused.
Second, IT/OPS are the owner of the infrastructure and thus things like connectionstrings. So theoretically, during deployment, IT/OPS fills in connectionstrings to databases and other stuff.
I get that ITOPS owns configuration data, and I also agree ITOPS owns the infrastructure. This would imply that ITOPS writes the infrastructure code too isolated from business service repositories.
As for how to structure infrastructure code across ITOPS repositories, that may depend on the resource and its cross-cutting concerns if any. For example, I would have a separate repo for creating a kubernetes cluster which is used by many web apps, and where a single web app requires a database instance I’d keep the database IaC code in the same web app repo. When I say web app here I mean a container for ACs. ITOps owns the web app, not the ACs.
Thanks for your input Dennis. You’ve helped clarify my thoughts.