Skip to main content

Innovation and Product Development

Understanding Infrastructure as Code

A group of diverse coworkers working on the computer together

Infrastructure as Code (IaC) is one of the most common terms we hear alongside every DevOps tool or concept. But what is it and how can we benefit from it? Let’s try to understand what IaC is all about. But first, let’s see a formal definition.

“Infrastructure as Code (IaC) is the management of infrastructure (networks, virtual machines, load balancers, and connection topology) in a descriptive model, using the same versioning the DevOps team uses for source code.” Source: Microsoft, What is Infrastructure as Code?

IaC tries to solve most of the problems with the traditional way to manage our infrastructure. This is achieved by converting every manual configuration into a human-readable code. That is, our servers, firewall setup, even our users and SSH keys can be codified in a structured manner to give us a complete definition of our infrastructure. This allows us to create environments in a safe and repeatable way.

Many tools give us this functionality but for now, let’s dive into the principal concepts that IaC enables us.

  • Version controlled infrastructure. Given that our infrastructure now is written into configuration files, it’s possible to get all our setup into version control. We gain the same benefits that we already have with the source code of our applications. We can have more visibility about changes in our code, thus we can view the evolution of our infrastructure over time. This is a huge benefit from a security and reliability standpoint.
  • Idempotence. IaC allows us to deploy our infrastructure with the assurance that every new environment will produce the same results no matter what. Regular infrastructure setup requires too many steps in different tools and web consoles; every step introduces possible errors, thus we are in danger of getting into trouble finding out that we forgot to set up the correct version of X dependency or that we let the firewall server turned off by accident.
  • Immutable infrastructure. This means that our infrastructure can’t be changed directly once it’s deployed. If we need to make some changes, we would change the source code (IaC) and redeploy everything. The benefit from it is that we reduce a common problem called configuration drift. This happens when our documentation no longer reflects what is running in our environments, thus we are in danger of introducing a new change taking into consideration the possible effects due to a forgotten change in the past.
  • Automation. Now that our infrastructure is managed by a version control system and we are safe knowing that every time we deploy our environment the results will be the same, we can take a step forward and put all those files into an automation tool to respond in a more agile way.

All this sounds cool, but why do I need it? Well, let’s start with the traditional way to manage infrastructure. Imagine that we are part of a small company and we run a very simple application.

Figure 1. Simple web app diagram

Apart from the code defining our application, this infrastructure requires more configuration regarding access controls, security management, scripts required to manage the services running our application, and every networking task related to our web server. Doing all the previous management by hand looks simple, but the problem is that for this configuration we would need at least two environments, which are our stage and production environment.

Now imagine that our company is moving faster and we need more space to develop the application, so another two environments are required. Tom, the guy in charge of setting up the last environment is now in another team and he doesn’t remember the details for setting up the infrastructure. Now you have to guess every part of the environment that allows your application to run. After some time doing your best, the environments are ready to go and the team starts their work.

Two weeks later, you push your application to the production environment and everything falls apart. Now you know that there was a hidden script in the production and stage environments in charge of starting some requirements for your application. You develop the app in an environment without those scripts and that causes the deployment to fail. It would have been very useful to have your infrastructure defined into code so you just take the repository, pull the trigger, and voila, your environments are ready, wouldn’t it? Just like you do it with your application every time you need it.

This is just a very simple example of what IaC can do for you. When our architecture evolves into more complex and distributed systems, introducing new changes in every environment it can be burdensome. Even the task of maintaining your documentation updated gets a lot more difficult.

Now it’s easy to see the benefits of IaC. Do you think this can be useful? Have you been in a situation similar to the previous example? The next step is to choose a tool and become familiar with it, then analyze the best way to translate all the infrastructure and manual configuration you already have in place into code. This is not an easy task and needs to be performed carefully.

We’ll dive into more of that in another blog post. We’ll keep you posted!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Perficient Latin America

More from this Author

Follow Us
TwitterLinkedinFacebookYoutubeInstagram