Hey everyone! I’ve been looking into Atmos couple of days now, and it looks really good for our use case. Something I am struggling with is how small I want my stacks to be split. We’re still relatively tiny SaaS company, but as we aim to be hosted on hyperscaler marketplaces, we probably need multi-cloud strategy (GCP being main one). We also do some consulting, and might host something outside of our core product, so I’ve utilized now “_namespace-tenant_” split, like in atmos docs. My name_template is currently:

"{{.vars.namespace}}-{{.vars.tenant}}-{{.vars.environment}}-{{.vars.stage}}-{{.vars.layer}}"

This leads to stack names such as:

mp-plat-gcp-non-prod-meta
 mp-plat-gcp-non-prod-network
 mp-plat-gcp-non-prod-cluster
 mp-plat-gcp-shared-meta

So far in the environment I don’t have indication of Cloud region, only the vendor. Not sure if I should have it? Environments will be only “prod”/“non-prod” split, we’ll handle app specific staging, dynamic preview envs etc. with Argo-CD inside the clusters. I’m heavily utilizing Google’s excellent terraform modules for project creation, shared vpc and K8S cluster management. These are already on quite high level / opinionated, so components right now are really lightweight. I’ve split layers like this: • meta: things like org settings, folder creation and project creation ◦ why: my thinking is project creation should be split off from actual resource stacks, project rarely if at all changes after creation, and it can be slow to validate everything • network -> shared VPC stuff • cluster -> GKE cluster creation • clsuter-addons -> what necessary stuff goes into Kube cluster, like Argo-CD As to applications, I don’t know yet. We’ll probably aim to have multi-app clusters, apps could be deployed totally outside of Atmos as well. Definitely considering Argo-CD there, which I’ve had good experiences. Any feedback would be appreciated here! Am I having too small stacks?

Ya those names are getting long… but at first glance looks good. I am going take a closer look later

@Erik Osterman (Cloud Posse) I realized actual state files that get created contain name of the component, in addition to anything I specify in stack name_template. Meaning, in layer named “cluster” I have probably just one component “gke”, or network layer has just one component named “network” 😄 A bit confusing. Maybe I should drop layered approach? Alternative might be that I split components much smaller, eg. network component splits into vpc creation, nat gateway etc. But this also sounds a bit ridiculous, spliting these things to separate tfstate files.

Our general guidance is not to make your components too small, because you don't want to try and recreate Terraform or HCL in YAML.

@Erik Osterman (Cloud Posse) Do you generally recommend one component to create multiple instances, let’s say accounts or projects.. or clusters using for_each? Or each instance should be it’s own instance of the component, thus separate root state as well?

That's the factory pattern