Infrastructure as Code

In this post we are going to talk about the most devops-related side of programming roles. But in today's world, just writing code for the front end or the back end is not enough. Some people prefer to focus on front and back, others pivot towards data analysis, and then there are others like me, who lean a bit more towards devops.

Doing devops doesn't mean you have to know everything about networks or load balancers; of course, we need a foundation in all aspects, but what we really need is to be able to read the documentation and, based on it, choose a good configuration.

1 - What is infrastructure as code?

Infrastructure as code or IaC, is a technique that allows us to provision our server infrastructure through software, in this case code. The aim is to achieve consistency and the expected (predicted) results.

1.1 - Through code

When we use IaC, we are writing code. This means that, for example, when we want to deploy a new web server, we do not go to our cloud provider like Azure or AWS and look for "add web instance" on the screen.

Instead, this process is specified in a file that contains all the configuration of our environment, and in this file, we will specify our new web instance.

And these files come in JSON or YAML format.

For example, in a JSON file we can specify that we want to increase our web server from 8 GB RAM to 12 GB, just by changing a number in the file. We don’t need to go to the server and change the physical memory manually.

1.2 - Consistency

By writing all the instructions in our configuration file, what we want is to always have the same results, no matter if we run the file once or 50 times, and no matter how many different environments. If you execute a configuration block in one environment, the result will be the same as in another environment.

This way we can execute our infrastructure as code files in all our environments (test/staging/production) and the result will be three completely identical environments. This is ideal for testing.

2 - Features of infrastructure as code

To understand the power of infrastructure as code, we need to understand several related points.

2.1 - Infrastructure as code is code

It may sound obvious, but we need to treat our configuration files as regular code. It is true that they are written in JSON or YAML and are usually typed with our cloud provider. But code is code, and as such, it is subject to change and improvement, so if we change something there should be someone to check that the change makes sense in a code review. And of course, it must be in the version control system.

2.2 - Declarative vs imperative infrastructure as code

As a general rule, when we write our infrastructure code, we do it in a declarative way. This means we write a file with the final configuration that our infrastructure should have.

Therefore, we are configuring the "what" we want, while in an imperative way, it would be the "how".

For example, if we want a web server with a load balancer and an alert if the server is overloaded, we need to specify in our file that we want a load balancer and reference this balancer on our server. Finally, we need to create an alert with the reference to our server.

By writing in a declarative way, the software (aws/azure/etc) will execute the necessary commands behind the scenes to make sure that configuration is applied.

One way to use the imperative style would be through the command line (CLI) of these tools.

2.3 - Consistency and variability

The strong point of infrastructure as code is that the same configuration executed against different environments gives us the same result.

For example, if we run a file that creates a web with a load balancer, whether it is in test, staging or production, it will create the website with a load balancer.

But what happens if we change the code, not our configuration file, but some other part?

A very important point is variability (Idempotence in English), which means that only the information that changes is re-executed.

So if we change a file in the code, our load balancer and website won't be affected by the change.

But if we increase the web’s RAM, then the configuration will change and the memory upgrade will be applied to all our environments.

3 - Benefits of Infrastructure as Code

3.1 - Automating deployments

Obviously, if we have all our configuration in files, we can automate everything so it gets executed and have CI/CD configured.

3.2 - Consistency in development environments

When we want to create a new environment, we just need to execute those files and everything will work perfectly.

In addition, this lets us ignore all the manual steps that on traditional servers could take us hours to fix.

3.3 - Reuse with templates

I haven’t mentioned it before, but configuration files are not unique; we can have files with groups of services and their configurations, as well as receive variables in them, etc.

For example, if we have 100 web services or 100 serverless functions, we don’t need to create 100 alert configurations for when memory gets low or CPU usage is too high. Instead, we have one file with a "template" in which we specify all the alerts, and then, every time we declare a serverless function, we call this file passing parameters like the function name, etc.

3.4 - Architecture is documented

By having all the infrastructure as code, it is automatically documented, which is a great step and a very good way to understand the system.

Conclusion

• In this post we have seen what infrastructure as code is, its features and benefits.
• Personally, I would say that the first time you want to move your infrastructure to the cloud, you usually do it through the interface since it’s more intuitive, but you soon realize that it doesn’t make sense. Code for everything is much better because, in the long run, it's easier to understand, and of course, you can't skip any steps if you want to replicate the information to other environments.
• The only downside is that the learning curve is high and the first few times it feels like you’re spending a lot of time on these files, but in the long run you save hundreds of hours fixing problems with missing components and other issues.
• Finally, I would recommend everyone to use infrastructure as code 100%. Don’t hesitate to try it yourself or encourage your company to make use of infrastructure as code because it’s very useful.