Best practices on keeping terraform code and application code


Are there any good practices on keeping terraform code and application code?

Currently for e.g. AWS Lambdas we keep the terraform code along application code as a one repository, but I am not sure if this approach is aligning with best practices.

I did found only articles which describe how to organize only the terraform code itself, and not application code + terraform code.

Do you have any thoughts on this?


1 Like

I was going to ask exactly the same question. So, I am too very much interested to know - what is the best practice?

Hi @mystycalprorok (and @MarkKharitonov!),

As is often the case with this sort of decision, there isn’t a universal correct answer that applies for all cases. It very much depends on the broader context you’re using Terraform in.

A guideline I like to follow when deciding how to decompose systems is that if two things will often change together then it’s helpful for them to be represented together in a single repository. On the other hand, for things which tend to change on a separate cadence (either because they are completely unrelated, or because your process calls for the change to be done in two steps and/or by two different teams), it can often be helpful to separate them to help represent the effective scope of changes.

For applications built in a “serverless” architecture, as we often see with AWS Lambda, it seems to more often be the case that the infrastructure and the application are effectively one unit: the lambda function is arguably both the infrastructure (the fabric the code is running on) and the application (the code itself).

For that reason, I’ve more commonly seen folks building applications in this architectural style keep their infrastructure configuration (whether managed by Terraform or otherwise) in their application repositories, rather than separately.

Conversely, in the other common architectural style where an organazation deploys a fleet of servers and then deploys code to those servers as a separate step, a separate repository describing infrastructure seems more common, because often that fleet of servers (and associated network infrastructure, etc) is managed centrally, while application deployment is delegated to separate application development teams.

With that said, I think the key is that both of those positions are motivated by social/teamwork concerns more than they are motivated by technical concerns, and you’ll know much better than I do how your team wants to work and any regulatory constraints you’re operating under, and so hopefully the above helps to think through the tradeoff for yourself and find the best compromise for your situation.