What is Infrastructure as Code (IaC)?

Infrastructure as Code (IaC) refers to the definition and management of IT infrastructure (e.g. networks, virtual machines, load balancers, firewalls, etc.) in a declarative manner, i.e as source code. Declarative IaC has the powerful property of immutability: one particular set of inputs (i.e. version of source code) will only ever produce one configuration of infrastructure.

As a result, there are business advantages in terms of speed, risk, and cost; as well as making it easier to incorporate true DevOps into a cross-functional team.

Setting up IT infrastructure used to involve screwdrivers; and typing shell commands into an appliance using a keyboard attached to a serial port in a noisy, cold data centre.

The processes were slow, expensive, and very prone to human error. Although disk imaging helped remove some amount of repetition, each server had to be manually configured with the right values to make it functional and usable.

Updates and patches to these machines also had to be applied manually, to each machine, and this effort required dedicated teams. The manual aspect of all this made it incredibly easy to end up with ‘Snowflake servers’ - ie servers that became unique within the estate.

Virtual Machines brought us a long way forward. Virtual networks even more so.

The dawn of cloud computing was hailed by a range of vendors providing us with a full offering of Infrastructure as a service (IaaS): VMs, virtual networks, block storage, firewalls, load balancers, gateways, specialised software bundles (e.g. AWS Lambda), and more. Everything required to host a stack - anything from a single application, to a sprawling orchestration of services - could now be created ‘on demand’.

By themselves, cloud platforms do not change the issues presented by doing things manually: resources can still, of course, be manually provisioned and configured.

Enter stage: declarative Infrastructure as Code (IaC).

Infrastructure as Code (IaC) is the definition and management of IT infrastructure resources in a declarative manner, e.g. source code.

Declarative IaC has the powerful property of immutability. The function that applies the code to the target environment (e.g. a cloud provider) is deterministic, which makes the creation of multiple, identical ‘environments’ trivial: for performance testing, security testing, etc., you can easily provision an environment that is almost identical to what your production environment will be.

Having development and production environments be as-close-as-possible helps to catch bugs earlier which may only appear in an integrated environment.

Storing infrastructure in code allows us the same benefits as regular code: immutable version control (e.g. Git), self-documentation, peer review, smaller incremental changes, and more. Version control and peer review also provide audit trails; which is especially important to many larger corporate users.

It is not a substitute for a proper understanding of concepts such as networking, load balancing, scaling, and infrastructure security. However, IaC does make these things far more accessible: bridging the gap between Dev and Ops, helping to incorporate and cultivate a [true] DevOps culture amongst cross-functional teams.

IaC provides us with another key benefit: transparency. The infrastructure that surrounds our application is no longer hidden away. There is no more ‘magic’. Engineers can understand, reason about, and adapt a configuration far more easily; which is crucial for when things go wrong.

The benefits of IaC are clear, and we would recommend it be used in anger wherever possible. Benefits are brought both to engineering and the business: IaC provides a great means for auditing change; infrastructure can be deployed and changed faster; there is a lower knowledge overhead; risk is lowered compared to manually provisioned infrastructure, and there are clear cost savings (perhaps no need for a dedicated infrastructure team).

It is also analogous to other technologies we’ve explored in this roundtable - Micro platforms are designed to achieve many of the same goals, and continuous deployment to production (CDP) can also encompass infrastructure.

Looking further ahead, it’s easy to imagine how IaC might lose prevalence as cloud platforms provide greater levels of abstraction for our applications and how we organise them: orchestrations of containers (e.g. Kubernetes), and functions as a service (e.g. AWS Lambda) are great examples of where most if not all of the infrastructure concerns are managed for us. However, most solutions to non-trivial problems will still require some level of customised setup - so it’s safe to say that IaC is here to stay.

Ref: Morris, Infrastructure as Code
Ref: Martin Fowler: Infrastructure as Code