What is the purpose?

[lpiob]

What is the purpose of a module that creates a one resource?

[pazmarianoj]

Hi @lpiob First thank you for using our modules. We appreciate your feedback. Regarding your question, it's partially correct that the module provisiones a single resource because that single resource has 3 different Inputs for configuration that might be reflected as 3 different resources configuration wise. Re-reading the code I realized that 'starting_position' is the input we might want to validate in order to decide which of the resources we need to provision. So they should be 2 and not 3 blocks.

Another thing to consider is that this module is written for TF11. TF12 or newer will not have 3 blocks of the same resource to consider the varieties but it will use dynamic blocks instead.

Going back to the original question, by writing this the way it was written, we allow a single module to support all available configurations for a particular resource. If you surf other modules written by us for TF11, you will see that this is a pattern for resources that receives different collections of inputs depending on a particular one.

Again, this is a deprecated way to manage combinations since TF12 has being launched supporting dynamic blocks. We have plans to release the TF12 version of this module so this logic will be gone forever. Hope this answers your question. Thank you and let us know if you need the TF12 version and we can prioritize it.

-- MP

[lpiob]

Okay, but why would I need to use this module and learn it's syntax when instead I could just learn how to use the one underlying resource that is created in effect.

I just can't grasp what's the added value of encapsulating one (or two) resources of the same kind into a separate module.

[pazmarianoj]

Yeah, now I understand your question better. Consider this: 9 customers needs to have a copy of your implementation. Following your approach, and if I'm getting it right, you will have 9 copies of the same resource spread. Eventually, AWS might do changes on the resource, and you will have to go and change your 9 resources one by one.

By using Modules, we can point all our 9 implementation to a particular version of it. If the provider mades changes on the resource, we just lunch a new version of the module, point all the 9 implementations to the new version (If you use terraform cloud, you can apply the new version ID to the 9 workspaces in 1 apply task), and you ensure that your 9 customers receive the same version of the code, validated and tested, by doing terraform init.

Now in TF13, we have Module dependencies, meaning you can make a Module depending on another Module. This opens the gate to Wrappers that can be a single Module containing several ones with dependencies declared and you just have to tell your customer to point to your Wrapper module and dependency manager will do the rest.

Might not be valuable for small implementations, but when you support several customers, having non-monolithic modules brings flexibility to your development.

Thank you for sharing your doubts with us.

[lpiob]

I see following problems with this approach:

• I can protect against changes in the provider by forcing my terraform to use specific provider version.
• I do not have any guarantee that this module won't disappear one day, or for example it's tags won't be updated to point to a malicious code. Of course this can be applied to any module and even terraform itself, so minimising the number of elements that my terraform relies on will minimize the risk.

I understand profits of modularization and code reuse, I just can't justify to myself using a module that creates just a single resource. The added layer of complexity and abstraction does not bring any benefits.

[pazmarianoj]

About your first point, that approach sooner or later will force you to do a bigger upgrade since there is no guarantee of backwards compatibility between Provider and API that I'm aware of. Meaning that API changes will make your code useless if the vendor doesn't want to spend time and money supporting legacy API. A kinda common scenario in Cloud Vendors.

To your 2nd point, even when it's not declared on our repos, you can consider all our modules "Open Source" and GPL v3 licensed. That means you can fork and have your own collection of modules. So the risk of loosing the module, or being victim of a bug can be reduced by forking and maintaining your own copies. That's what we do regularly, and I would say that the whole community is doing it that way based on what I've read around the Terrafom's Official registry.