patternterraformMinor
Should I use multiple Terraform projects or only one?
Viewed 0 times
projectsonemultipleshoulduseonlyterraform
Problem
I am starting to build a Terraform GIT project to build resources for azure.
Currently my idea is to have a project that is taking care of identity and access topics & to have a project that is taking care of infrastructure topics.
Is it a good idea to have multiple terraform projects for different topics, or would it be better to just have one terraform project that is creating all resources for my organisation?
Currently my idea is to have a project that is taking care of identity and access topics & to have a project that is taking care of infrastructure topics.
Is it a good idea to have multiple terraform projects for different topics, or would it be better to just have one terraform project that is creating all resources for my organisation?
Solution
First of all, I propose a change in terminology. What you're calling a "project" should be referred to as a "module".
An environment is built out of a composition of modules.
This is a design decision. A key part of architecting a cloud environment is to design its components in a such a way that you can maintain them independently. In terraform, these come in the form of modules:
You can use modules to create lightweight abstractions, so that you can describe your infrastructure in terms of its architecture, rather than directly in terms of physical objects.
Instead of having a huge lump of resources, you have a set of building blocks which express higher levels of abstraction. An example might be "compute cluster". This will be comprised of the instances, the networks, block storage, object storage buckets, access permissions, etc, all packaged in a module. If this concept (compute cluster) is a useful one for you, then you should design a Terraform module which encapsulates them, so that you can reuse the concept.
There is a tradeoff to be made between tiny modules (ie single resource), and mega-modules (ie, all the resources).
Consider your architecture, try to identify which components are re-usable and build modules out of those. To make an analogy with construction: a window and a door are both re-usable components. A wall is a useful concept, not a brick.
An environment is built out of a composition of modules.
This is a design decision. A key part of architecting a cloud environment is to design its components in a such a way that you can maintain them independently. In terraform, these come in the form of modules:
You can use modules to create lightweight abstractions, so that you can describe your infrastructure in terms of its architecture, rather than directly in terms of physical objects.
Instead of having a huge lump of resources, you have a set of building blocks which express higher levels of abstraction. An example might be "compute cluster". This will be comprised of the instances, the networks, block storage, object storage buckets, access permissions, etc, all packaged in a module. If this concept (compute cluster) is a useful one for you, then you should design a Terraform module which encapsulates them, so that you can reuse the concept.
There is a tradeoff to be made between tiny modules (ie single resource), and mega-modules (ie, all the resources).
Consider your architecture, try to identify which components are re-usable and build modules out of those. To make an analogy with construction: a window and a door are both re-usable components. A wall is a useful concept, not a brick.
Context
StackExchange DevOps Q#17812, answer score: 1
Revisions (0)
No revisions yet.