Infrastructure as code

Infrastructure as code is basically the process of managing and provisioning your resources through definition files or code. It provides a centralized way to manage configuration in terms of implementation and version control. Suddenly, the resource management and provisioning becomes much more like the agile process in the systems-development life cycle in software. All changes are validated, tested, and provisioned as part of a release process and using standard deployment pipelines. This also provides the ability to copy configuration used to deploy infrastructure in one region to another.

For example, let's say you deployed infrastructure in the North Virginia region using code and configuration, you could easily modify it to make it work in the Ireland region too. This allows you to scale out very quickly in terms of your configuration around the infrastructure and this led to the development of the term DevOps. This is where developers get much more involved in the configuration, especially around the infrastructure, and the ops team (or operations teams) gets much more involved in the development process. The following diagram shows the different benefits of infrastructure as code:

There are many benefits in using infrastructure as code. The first one is cost reduction, as you expend a lot less effort on simple and repetitive tasks. You can also reduce cost when scaling or deploying similar infrastructure.

When building any system, I usually like to build it so that it works with two environments. Once it works for two, it will work for many. For example, if you build code with a naming convention as a prefix or variable for each environment, such as dev for development and stg for staging, and substitute it when deploying it, then we can easily later add a prd prefix for production. Using a standard naming convention is always highly recommended. Another example could be to always have three characters as a convention or rule, so that you will not get into the situation of having multiple prefixes, such prod or production, that can introduce unexpected errors. In a config file, the environment variable that would get substituted could look like ${env}.

The other point is the speed of execution; that is, your administrators or DevOps team can actually release infrastructure and services a lot faster than they would have done before. In addition, there's a reduction in the risk of errors that can be introduced, for example, through manual configuration or user-interface changes. Also, having traceability, validation, and testing at each step helps reduce the number of errors and issues. Overall, this helps reduce risks and improves security. Since you have this traceability, you can understand what was deployed and find out whether it was successful, or whether it's causing an issue and should be rolled back.

Table of Contents for Infrastructure as code

Create new playlist

Sign In

Sign Up

Table of Contents for
Infrastructure as code