[redeux]

I also think about layers when I set up IaC, but I'm more focused on how things connect and relate rather than sticking strictly to the OSI stack model. In my mind, it's all about grouping things that might influence each other. This approach usually leads me to think in three layers: foundation, shared services, and applications.

Starting at the bottom, the foundation layer holds the basics like networking, storage, accounts, and permissions. The shared services layer is where I place tools like certificate managers and secret storage. I keep services that interact closely together, while separating those that work more independently. At the top, I lay out the applications. This is where I slot in services like auto-scaling groups, individual server instances, load balancers (depending on whether they're communal or specific), and pods in platforms like Kubernetes. Depending on the complexity of the environment there may be 1 or multiples of each layer.

By structuring IaC this way, I find it’s clearer and more intuitive.

[FujiApple]

This is very similar to the layering approach I ended up with for a service I built a couple of years ago (AWS using Pulumi).

Global - Things from the AWS global region, notably DNS (DelegationSet and Zone) and IAM

Core - Semi-permanent per-stack resources such as secrets and certificates

Network - Network resources per-stack (ie. VPC & EC2)

Database - Database resources per-stack (i.e. RDS) and rotating secrets (via Lambda)

Application - Application resources per-stack (i.e. ECS)

Breakglass - Resources for breakglass shell access to the DMZ subnets

[hermanradtke]

What I like about this approach is that it maps well to different teams. The ops team can own the bottom 3 and product teams can own the top 3.

[stevekemp]

I'm using something similar at the moment, and it mostly works. There are issues now and again though - if the developers of a service own the "top" layers, and start adding new services then that often requires changes to the core.

For example if a team were to suddenly start using DynamoDB then the IAM roles for their application, in their account, suddenly need the permission to add/get records.

Most of the time the layers are distinct and the "ops" team can handle the core, leaving the application/service-specific stuff to the developers, but things do come up that have to be scheduled and coordinated across the layers/owners. It's a pain, but so far tolerable one.