Explaining infrastructure as code (IAC) on the example of Terraform

The aim of this page📝 is to explain the concept and basic qualities of infrastructure as code.

1. IAC is provisioning infrastructure through software/code to achieve consist and predictable environments

• through software/code — not manually
• a) consistency ⟹ no mistakes done via manual config often
• b) predictability ⟹ looks like config files say it should look, essential when one has multiple environments running the same app
• c) scaleability ⟹ it is possible to quickly make 1 change to n (1000s) of accounts with text/code modifications
• IAC is defined in code ⟹ using configuration files: .json, .yaml, hashicorp config language
• IAC is defined in source control ⟹ usually git+github, developers can simulteneously work on config files

You benefit from ✔️ automated deployment: no need to go through manual steps evry time you need to build an environment.

• I remember, in my old job, the the most used KB doc was a doc how to build a server and there was a dedicated teams building servers/virtual machines, going through the checklist, leaving us wait for days until the server arrived ✔️ consistent environments: a step will not be forgotten during manual configuration ✔️ repeatable process: config will be instantiated and you know you have a repeatable process ✔️ DRY (reusable components): config/abstractions can be taken, say for a DB server, and can be repeated for similar needs ✔️ documented architecture: code is great documentation of architecture

2. There are two approaches to IAC: declarative and imperative one

• terraform is the declarative approach to deploy infra, similar to Mermaid is a declarative approach to construct a diagram
• you don’t tell Mermaid how a diagram is supposed to be constructed
• you only use Mermaid language to define the components you need and you leave the construction itself to be done by the library
• there are imperative approaches

3. IAC is idempotent, which is why you can freely apply as many times as you want (say I am deploying a data processing pipeline)

• is idempotent — i.e. it has the state awareness
• that if there is no change to the config, but there is another repetition of the request, the request will not be performed — it can see if it is properly synced
• terraform uses push (not pull) approach to deploy infra
• Terraform is known for the concept of idempotency.
• The idempotency feature of Terraform ensures that only the necessary changes are made to the infrastructure to reach the desired state even when the same configuration is run multiple times, thereby avoiding unwanted drift of infrastructure state.
• This is important for automation tools because they can be run to change configuration and also to verify that the configuration actually matches what you want. There are many examples of idempotent operations in mathematics and computer science. Here are a few:
• In mathematics, an idempotent operation is one where f(f(x)) = f(x). For example, the abs() function is idempotent because abs(abs(x)) = abs(x) for all x³.
• In computer science, an example of an idempotent operation would be updating the contact details of a user in a system. Let’s say we update only the telephone number. The side effect of this update is that we send a text message with a verification code to the new number. If the update message is sent again, nothing will happen and the text message isn’t sent for a second time¹.
• Another example of an idempotent operation in computer science is the HTTP DELETE method. When you send a DELETE request to a server to delete a resource, if you send the same request again, the server will return the same response as if the resource was deleted, even though it was already deleted in the first request.
• In Terraform, again, if there’s no change to the config files and you apply the config files again, nothing is changed in the environment

5. IAC can be pushing or pulling, and terraform is pulling

• Terraform is a push type model
• Configuration is pushed to the target environment
• The opposite — the pull model — would mean that there’s an agent in the target environment and it is pulling config from a central source on a schedule
• Some examples of pull-based infrastructure as code tools are Puppet and Chef.
• These tools use a master-agent architecture where the agents on the managed nodes pull the desired configuration from the master server and apply it to the local system.

6. LINKS

https://stackoverflow.com/questions/1077412/what-is-an-idempotent-operation https://www.baeldung.com/cs/idempotent-operations https://en.wikipedia.org/wiki/Idempotence https://learn.microsoft.com/en-us/devops/deliver/what-is-infrastructure-as-code https://cloud.google.com/recommender/docs/tutorial-iac https://infrastructure-as-code.com/book/2021/01/02/pull-requests.html https://www.trustradius.com/infrastructure-as-code https://techcommunity.microsoft.com/t5/itops-talk-blog/infrastructure-as-code-iac-comparing-the-tools/ba-p/3205045