Context
In the age of cloud computing, provisioning infrastructure became easier through cloud providers. At the same time, there was a need to improve the developer experience to avoid the so called “click-ops” and make the infrastructure definition replicable, versioned, and automated.
As the name suggests, IaC addresses this need through, as the name suggests, defining the infrastructure as a code itself, that can be managed just like any other project and frequently alongisde the application code itself.
Idempotence
In computing, idempotence is a property of an operation that produces the same result regardless of how many times is executed.
Imperative vs Declarative
To-do…
Shared infrastructure
Sometimes, you would need to share the same infrastructure resources across multiple projects or repositories. For example, I’ve seen this pattern a lot with networking resources, such as VPCs and subnets.
If you are going with a multi-repository approach, you can create a dedicated repository for the shared infrastructure resources and then reference them in your other repositories. This way, you can manage the shared resources independently and avoid duplication, as well as versioning them separately. This approach is often referred to as “infrastructure modules” or “shared modules”.
Another approach is to use a monorepo, where you can have all your infrastructure code in a single repository. This way, you can manage the shared resources alongside the application code and avoid duplication. However, this approach can lead to a more complex repository structure and may require additional tooling to manage dependencies between different parts of the codebase.