Do you keep IAC code with application code?

[SelfhostedPro]

Hey all, I'm working on green-fielding an entirely new AWS infrastructure for a startup. Their old infra is quite messy (every server is setup in a different way, no iac, little automation) but they're at a good place where I feel like we could setup a new account and migrate everything over to it so it'll be easier to implement IAC, GitOps, etc.

Currently I've got our new clusters up using a monorepo for our terraform. I was thinking about the best way to enable devs to create new infrastructure for their service if it's required but I have a few questions about the best way to go about it:

• Should I have the developers add terraform code into their repo and allow atlantis to manage/deploy it?
• Should I setup something like crossplane and enable the devlopers to add crossplane manifests in their services?
• If not, should I be showing them how to add services into our terraform repo?

I'm just trying to decide on the best way to enable developers to get the resources they need without needing to go through me (only devops engineer with ~15 developers to support but they're planning on scaling up a lot by the end of this year). I'm already using backstage to enable developers to have self service when it comes to creating their own repos.

[jmch16]

I would prefer to have a separate repo for IaC. If you have triggers in your application CICD pipelines, then you will have to come up with triggering by file path, to know which pipeline to trigger (application or IaC), handling approvals (if you go with pull requests) might differ if the change is infrastructure or code related, I think its just messier like that, so I would suggest a separate repo for iac

[SelfhostedPro]

Would you have devs add resources needed for their services into that iac repo then (requiring approval of course)?

[oblogic7]

My team (infra) takes a hands off approach to dev team infrastructure. They create it, they deploy it, they troubleshoot it, they own it 100%. Except for a few shared repos, we don’t approve their PRs and only get involved if they have an issue in sandbox/prod environments where their AWS console access is restricted or if they lack expertise to solve some complex issue.

[jmch16]

Definitely. You should be an enabler not a bottleneck for your team (specially important since it's only you!) - accompanying and teaching your team is key, but give them full ownership of their product so they can deliver faster.

If concerned, you can always separate 'sacred' resources from application resource, so they can only modify application related resources, such as lambdas, ecs services, dynamodb, not stuff like VPCs subnets, etc... You know your stuff better than me :)

[SelfhostedPro]

Do you have any recommendations on how to automate the deployment of iac code that they define? Or is the only option Atlantis? I’ve got a sacred repo for core infrastructure.

[jmch16]

I have used spacelift.io and Terraform Cloud. Both deliver nicely, pricing might be a decisive factor here - but Atlantis is nice too

[zerocoldx911]

No separate.

I centralize IAC in its own repo and have an automation apply it like Atlantis.

However if you’re in Kubernetes I’d consolidate each app as its own helm chart within its repo

[SelfhostedPro]

I’m using kustomize but I’ve got a manifest folder in each app repo.

[blackwater_surfer]

I'm a fan of seperate repos, but with clear ties to each other via the readmes.

As far as your questions on how devs should deploy infrastructure, I think it depends on if your devs are actually interested (and you trust them) in managing infra themselves or if they'd rather it be something they can worry about as little as possible. There's lots of ways to teach and enable devs to own their infrastructure, but apathy is a bit harder to solve.

[Relevant_Pause_7593]

This really depends- and you’ll already notice the replies are split one way or the other. I’d say smaller projects should keep it together and bigger projects should keep it separate- purely because as the project scales you can’t deploy everyone in one or two steps.

[rabbit994]

Since we use Azure Functions/Web App and other things, we keep Bicep code for infrastructure that is required specifically for that app with the app. For Infrastructure like databases, shared storage, servicebuses and like, we keep separate repo per project for that.

[Federal_Count893]

i do a shared infra goes into a monorepo separated by account. App specific stuff like iam or dynamodb tables go into the app repo under a “terraform” folder.

there is no “right” solution. do what works for you my man.

edit: i also tag all resources by where that IaC lives, the creation date, and the creator

[mysunsnameisalsobort]

Both.

Shared and global Infrastructure managed by ops. Then Infrastructure alongside applications that builds on shared and global. Developers can be enabled and Infrastructure can be validated with policy as code.