What is infrastructure as a code

To make the most out of your software, you must start building infrastructure as code with procedures, tools, and practices. This ensures that all changes are planned, recorded, and tested before they go live which improves development efficiencies.

Infrastructure as code can be done by using anything from a visual text editor to a build tool like Jenkins or Gitlab. The code can be hosted on version control such as Git, SVN, or GitHub. The code could be stored in a database, for example, MySQL or Postgresql.

Infrastructure as code is the process by which one takes all written documentation of the infrastructure and makes it automatically available to all employees with the ability to make changes that can then be tested and validated before going live.

For example, you could choose to store your system configuration files (Nginx configs and ELB configs) in a Git repository that is managed with Jenkins. You could store your environment data such as Nginx logs in another git repository on GitHub and generate a series of Terraform scripts to load those configurations into production environments.

You could also use a Docker Compose file to orchestrate your Nginx, monitoring, and compute containers.

All the above might seem like a lot of overhead and overhead means more work. That is where infrastructure as code starts to pay off with less work. By generating these scripts from Terraform, Cloudformation, or whatever tools you choose you can have them ready for use in under 15 minutes if all you have is a text editor. The time spent creating and testing these scripts will save you time when deploying changes to production.

Infrastructure as code gives you full control over the infrastructure that is running your applications. It reduces the need to ask questions such as "Did you remove that file from production last week?" or the dreaded and depressing "I think there might have been some problems in my Nginx config". Now, this kind of knowledge is stored in the infrastructure code that can be checked for accuracy and recreated at any time.

This is where working with open source software and configuration management comes in handy because you have all these tools available to do this work for you, but often with a much better user experience than what these tools offer by default.

When you are building a new application, you can test it on a virtual machine that is running the same configuration as production. This gives you the confidence and know-how to go live once you have verified that the application works correctly. The same practice applies in managing changes to production servers thanks to automation and infrastructure as code.

Infrastructure as code offers several benefits including:

Making it possible to have an identical environment for testing in development, staging, and production environments. This offers more confidence when going live, as well as reduces time spent when making changes to systems.

Infrastructure as code offers the ability to make changes to the infrastructure without having access to production servers and networks. This can be done either by using a cloud provider that offers test environments or using a testing server for development purposes.

Automating the deployment of your application can give you confidence that it will run in the production environment once it goes live. You will know that any changes made in the staging or development environment are automatically applied to the production environment as long as you don't modify the source code directly, which should rarely happen. It is recommended to use pull requests for most deployments.

Infrastructure as code is not automatic, but it does make it possible to automate a lot of things that change regularly. For example, you can make your scripts to orchestrate your build workflow (Jenkins, Gitlab CI, or whatever), and then store these scripts in a Git repository that is managed with Jenkins or Gitlab. You could also automate the deployment of your application to the cloud or virtual machines with Puppet, Chef, or Ansible. You could create a script that checks whether there are any license usage issues before deploying an application with Terraform or Cloudformation. In short: Infrastructure as code makes it possible to automate everything that changes regularly and save time by doing so.

When using infrastructure as code, you will find that not only do you save time making changes, but your application behaves the same way in staging, development, or production environment.

For example, let's say that you have an application that uses AWS RDS for its database and does some heavy processing on the database where it is generating some reports. You need to make a change in the RDS instance and run some SQL scripts. With infrastructure as code, you will be able to use an online tool such as SQLCipher docs or something similar to generate these scripts from your configuration files. Then all you have to do is apply these scripts to your running DB instance and re-run the reports.

With infrastructure as code, the time you spend making changes will become a thing of the past. It is possible to have a fully automated application that can be updated with one command, such as git push.

Infrastructure as code is not only useful for teams or infrastructure engineers. A lot of developer teams are embracing infrastructure as code and starting to use it to manage their production infrastructure and environments. Some of the benefits include:

Benefits for developers:

Managing configuration changes in staging or development environments are made easier thanks to tools such as Terraform or Cloudformation.

Since source code is used to create infrastructure as code, it is less likely for developers to make mistakes when making changes to the environment.

Simpler deployments to production thanks to automated scripts and tools. This will allow teams to focus on developing their applications instead of having to spend time maintaining the infrastructure they create. These types of automated processes also make it easier for developers to iterate faster with better processes as they are not spending more than 20 minutes a day to deploy a new version of their application.

Automating the deployment process can reduce maintenance costs by eliminating downtime caused by failures or unexpected behavior within the application.

Infrastructure as code gives developers the ability to quickly integrate their application and experience with it before going live. Developers can use the same source code for both development and production environments, allowing for faster iterations.

Benefits for system administrators:

You will get better visibility and a shorter time to diagnose issues that arise when an application misbehaves in production (as opposed to having to restore or re-deploy it manually). If a new build is made available, you have access to the latest version of your application without having to wait until you are seeing the changes in a production environment.

The time spent making changes to your infrastructure will be much more efficient. This will allow you to make changes faster, with less risk of failure.

Mass deployments to production will be faster and easier thanks to tools such as Puppet or Chef. These tools automate the most common tasks that change regularly when managing infrastructure.

With infrastructure as code, you can use a single source of truth for everything related to your environment and application, which makes it easier for you to manage everything in one place. For example, you can use Ansible as your main tool for task automation and configuration management. Ansible can then be used to deploy your application with Chef or Puppet. You don't have to use Ansible for these tasks, but it's used as an example of how everything can be handled in one place.

You will have a lot of flexibility with the tools you choose to manage your infrastructure. There is no single tool that suits all companies and their needs, and we believe that tools should be chosen based on their own merits rather than what has been around for a longer period. Regardless of this, most teams will start with some sort of configuration management tool such as Puppet or Chef since these tools are easier to get started with and usually enough for most cases.

Infrastructure as code makes it possible to deploy your application with a single command: git push. You can run your tests and get the same output in staging or development that you do in production. Using infrastructure as code will allow you to iterate faster and test your application in production before going live.

Reasons against:

While infrastructure as code is very useful, there are a few reasons why you might not want to start using this today including:

Not enough time - Certain tasks take longer than others (such as setting up a new environment or making changes). Infrastructure as code is not the silver bullet for solving these issues; instead, it allows us to spend our time more efficiently. Our time is better spent making changes to our applications instead of building a new environment.

Not enough experience with the technology. This can be solved by taking the time to learn the benefits of using this type of tooling or hiring an experienced DevOps engineer to help you get started.

Culture - Some companies are still used to working in ways that do not maximize their resources and are happy with it. They think that "if it ain't broken, don't fix it". It's harder for them to change how they architect their applications and make changes since this goes against most established practices that have been around for more than 20 years.

This is not for everyone, but it is for most companies. I believe that one day it will become the standard way how we design and build our applications and infrastructure. If you want to save yourself time and focus on building your application instead of spending time making changes to your infrastructure, then keep an eye on this space. There are a lot more tools that are being released every month that simplify our lives as software engineers. Keep an eye out for them too!

In the following sections, we will explore some tools that are worth looking into: configuration management tools and code repositories such as Git or Mercurial (Hg).

Configuration management tools

A configuration management tool is a piece of software that we can use to manage the environment for our applications. This includes the operating systems and other necessary components (such as database servers, web servers, etc.). We use configuration management tools to create immutable infrastructure by allowing us to define how everything should be set up before running a new application. For example, if we need to add a new server and run it in production with Ansible, Chef, or Puppet; we would first create all the necessary components for our development, testing, and staging environments for that specific application. Then, once it is finished being developed, tested, and ready for production release then we can deploy the application to the desired locations.