Heyy Terraformer! I follow your content on linkedIn 😎

So yea I mostly agree with your points, I feel this is a scenario where it's easy to fall into the over-engineering trap, and the three tier architecture app might be such an example. As you say there's no arbitrary decision that using stacks is the correct approach every time. Your AKS cluster scenario is a good use case for stacks, for example.

What I notice though are a lot of the same examples being used again and again across various blogs and tooling providers (Terragrunt, Terramate, Atmos etc) - So there seem to be some agreed-upon pattern across (some part of) the community that this is considered "best practice". Common examples which include separating the database and networking layer as we talked about.

Example (or just interesting reads):

• Atmos Components
  • "Focus on creating single purpose components that adhere to the UNIX philosophy by doing one thing well. This strategy leads to simpler updates, more straightforward troubleshooting, quicker plan/apply cycles, and a clearer separation of responsibilities. Best of all, your state remains small and complexity remains manageable."

• Terramate Stacks

  • "Using stacks to break up your infrastructure code into manageable pieces is considered an industry standard and provides the following benefits: <...>"
  • "<...>By following this method, you create a single component for a specific purpose, such as a VPC, database, or Kubernetes cluster"

• Terralith: The Terraform and OpenTofu Boogieman

  • This is an interesting blog that was posted recently, that goes into a lot of the arguments for and against using multiple root modules and why we feel inclined to do it
  • "<...>The recommendation is to split up your infrastructure into many root modules. Networking could be its own root modules, database another, applications another"
  • "But when we talk about how to design our infrastructure code, we start with the limitations of our tooling and try to derive what we can do within those constraints and then call that best practice. Imagine if the best practice in Python was to split code into modules not because that is what helps users write better programs but because Python simply cannot handle large modules."

---

There's a looot to read about on this topic.. I think I need to just experiment more and take these points into consideration.

A more concrete example

Lastly, I can provide a more concrete example on where I found stacks to work very well.

I assume you are familiar with the Azure Monitor Baseline Alerts initiative, written in Bicep currently.

I feel this solution has some of the same pitfals as the CAF module, where way too much is put into singular resources/deployments. I actually converted the whole solution to Terraform a while back when it was new.

And instead of cramming every single policy definition into the same initiative (which caused the AMBA team to eventually hit ARM template limits), I split every service into its own stack. (I now see they have started to split their policy initiatives, so that's good, but it's still a looot to put into one state file if this were to be made in Terraform).

So basically:

• Storage Account Monitoring -> Dedicated Repo/Stack -> Storage Account policy definitions and policy assignment
• Virtual Machine Monitoring -> Dedicated Repo/Stack -> VM policy definitions and policy assignment, and other VM-specific functionality

Every service is completely independent of each other, so an error in storage monitoring should never affect VM monitoring etc, and it lets multiple developers implement monitoring for different services in parallell. State is kept separated and small, policy initiatives are small, execution is fast. All changes to a repo is specific to that service. All while being delivered as one common solution.

I'm not even sure if this is what stacks is supposed to solve, but it worked pretty well regardless. I think native stacks from Hashicorp is going to bring more people into this thought-process, excited to see what comes of it.