Hello,
Let’s say I have 2 modules:
- AWS VPC - Creates a VPC, subnets, etc.
- AWS EKS - Creates an EKS cluster in given VPC
In some situations, there is already a VPC and I want to only use the EKS module. I’ve supported this situation in two different ways.
Scenario 1: Import the preexisting VPC into the VPC module, requires a lot of iteration getting it to all match after the import.
Scenario 2: Don’t use the VPC module at all, pass the preexisting VPC ID, Subnet IDs, etc. to the EKS module.
In this situation, Scenario 2 worked out great. I never tried Scenario 1.
New project, new problems.
In a similar situation, I have 2 modules:
- Azure Storage - Creates storage account, creates Azure File systems.
- Azure AKS - Creates an AKS cluster, using the given storage account.
For a new environment I’d run both modules, no problem there. Once again, in some cases we’re migrating preexisting clusters + storage accounts into Terraform control.
With this one I’m leaning more towards importing because we do sometimes make changes to the storage resources.
What do you guys think?
Hi @taylorturner,
It sounds like you are practicing the principles described in the Module Composition guide, of building modules that are decoupled enough that the can be combined together in different ways as needed.
One of the key advantages of that model is that the decision you make today doesn’t need to be the decision for all time: if you have a single configuration containing an instance of an Azure Storage module and an instance of an Azure AKS module, you can later decompose that into two separate configurations by designing a way for the results of the Azure Storage module to be published somewhere that the configuration with the AKS cluster can fetch it, without changing either of the modules themselves.
Of course, that sort of refactoring will require state manipulation to apply later, so it’s certainly not free as a result of using module composition, but it does at least avoid making significant changes to the modules themselves, which means they can be shared with other configurations where you made different composition tradeoffs.
With all of that said: I don’t think there’s a single right answer to this question, but if I were in your situation and unsure how to proceed I would personally take the “all in one configuration” approach as the default/tie-breaker, because it’s the simpler of the two and I prefer to err on the side of only introducing complexity where there’s a clear need for it. If you later find a justification for the complexity of decomposition, you can separate the two at that time and use terraform import and terraform state rm to reshape the states to suit the new design.
1 Like