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, teams, and so on. I’ve seen this a lot with networking resources, such as VPCs and subnets.
In cases like this, is important to reduce the blast radius of changes and enable reusability.
Blast radius is reduced by havning a granular state. The more isolated a state file is, the less damage a single apply can do.
Some general recommendations for keeping the state granular:
- Group things by how frequent they change: stable resources should be isolated from resources that change frequently, so you don’t risk affecting their state by accident.
- Group things by dependencies: if a resource is depended on by many other live resources (e.g. a shared VPC), it should be defined in its own state. This not only limits blast radius but also allows you to restrict write-access to the shared resource.
Reusability, on the other hand, is addressed through shared modules, which can be defined in a dedicated repository or as part of a monorepo. A module is just reusable code, it doesn’t carry state, so the same module can be instantiated many times by different configurations that do carry state.