Engineers now have the capability to encode their infrastructure choices and save them in a repository. This allows them to save time, reduce risk, share knowledge, and create transparency in change.

What is infrastructure as code?

Infrastructure as code (IaC) is a way for engineers to write code and configuration files that are converted into working infrastructure. The configuration is generally saved in a code repository, so the team can review any changes before applying them, just like code reviews.

Save time

In the short term, infrastructure as code requires a time investment. However, this saves time in the long term. By making the management of your infrastructure less labor intensive, your team can spend more time focusing on development work and delivering value to customers.

The time for setting up redundant infrastructure or test environments is also drastically reduced, resulting in less friction. This improves the resilience of your organization in the long term.

Another benefit is the reduced time needed to onboard or offboard team members and rotate security keys. New hires can grant themselves the right permissions when the system is properly configured, supported by an approval process which ensures security. Access (or not) can also be coded, automating the onboarding (or offboarding).

Reduce risk

IaC prevents your team from making mistakes. By scripting the changes you would otherwise apply manually, you reduce the risk of human error and configuration drift. Inconsistencies in configuring servers, environments, or services — ones that should be the same — can be avoided with infrastructure as code.

What is your infrastructure recovery process? With IaC, it's easy to recover when needed. When things go wrong, it's stressful and easy to make a configuration mistake or forget how a system works.

Infrastructure as code gives you the blueprint of a system that you can reapply consistently, at will. Anything from the number of replicas of your data to open port numbers to the size of your compute instances, infrastructure as code gives you complete control over how the system will be rebuilt.

Testing configuration changes, load testing, and chaos engineering become easier to execute since creating an environment that perfectly matches production is a snap of a finger. The team will be able to analyze how changes impact the system more quickly in a totally separate environment.

Most teams have just one or two people that understand the complete system. What happens if these people leave the team because they are ill or have won the lottery? Building infrastructure as code reduces this risk.

Sharing knowledge

Changes

When state changes occur, the team can easily track and follow the changes (using pull requests and issues). This is only possible when IaC is versioned just like the rest of your codebase. This increases transparency and knowledge and can allow for better bug-tracking if something goes awry.

Documented

Documenting infrastructure is often an afterthought for an engineering team. One person may have taken the time (a long time ago) to create an infrastructural diagram and some technical documentation. It probably doesn't match the current state, either.

That's when infrastructure as code truly shines. When leveraging IaC and declaratively defining your infrastructure, the documentation has been created simultaneously. The code is the documentation of the infrastructure, and it will always be up-to-date.

Collaboration

It’s easier to collaborate on a system that uses infrastructure as code. When changes are made to the system, there is no need to send a Slack message, ensuring that everyone makes the same update locally. Instead, the system is automatically configured.

Accessible

Since the configuration is stored in a code repository, it's also transparent. New team members can easily access the configuration and understand how a system works. They'll also be able to get it up and running locally without (much) help.

Visibility of changes

Manual changes to infrastructure, such as firewall port openings or auto-scaling threshold updates, may only be known to the author of these changes. This can set the team up for unexpected surprises when the original author is not around. The team cannot quickly troubleshoot the resulting issues or may even make a problem worse.

Applying the same processes to managing infrastructure code as to managing application code, such as version control or pull requests, increases visibility of changes that would otherwise go unnoticed.

Reaction to errors can be tremendously improved if the team reviews changes applied to the infrastructure. Furthermore, automated checks that are part of the Continuous Integration (CI) pipeline can further validate changes against common vulnerabilities or reject the ones violating established company policies by using tools such as Hashicorp Sentinel.

Furthermore, storing IaC in version control constitutes an audit trail of its own. It is possible to go back in time and review changes applied in the past, for instance those that may have opened up the system for a vulnerability or triggered resource exhaustion. This can be fed back into the retrospective process and provide further learning opportunities for the team.

By using infrastructure as code from the start of a project, we think you will have an easier time sharing knowledge while reducing risk. This translates to time saved. Give it a go and you'll enjoy the benefits we've listed above.