Put simply, Infrastructure as Code (IaC) allows you to define your IT systems and infrastructure in software. This is a powerful technique which has revolutionised the way that resources are commissioned and their lifecycle managed and maintained.
Infrastructure as Code can be achieved in many ways. Either by using a public cloud such as AWS, Azure or GCP or any other service provider. They all offer a way to natively define and re-use resources such as AWS’s Cloudformation (templates), Azure ARM templates and so forth. There are also third-party tools such as Hashicorp’s Terraform, Ansible, Chef, Puppet, Pulumi and many others. Alternatively, you can configure using virtual machines on top of hardware in your own datacentres, run multiple containers on a single machine (virtual or real) or use a more heavyweight and microservices-oriented abstraction such as Kubernetes.
So why is this revolutionary?
Defining infrastructure as code allows you to take your configuration to another provider or another type of system.
You can reliably and quickly provision exact copies of infrastructure for example to build a Development (DTAP) street or alternative environments.
Having your virtual hardware configuration stored in code means that it’s possible to scan it for potential security issues and also enforce policies for Identity and Access Management (IAM) and Role-Based Access Control (RBAC) to ensure that not just the authorized people have access to the correct resources but also that there is an administrative paper trail for the purposes of audit and compliance.
Many IaC implementations use a declarative syntax which means that you specify what you want and then the platform creates it automatically – therefore you don’t have to specify the steps to build what you want. This automation speeds up the creation of infrastructure to as fast as the platform can provision it.
Full responsibility for a software solution starts with making as much of the configuration and definition of the delivered solution into the hands of those responsible. Achieving DevOps, in order to prioritise your customer, is therefore predicated on putting as much of this control in the right hands – the hands of your team.
Why is IaC Important?
Here is a great definition albeit it at much more detailed level from the Microsoft Azure pages:
Infrastructure as code (IaC) uses DevOps methodology and versioning with a descriptive model to define and deploy infrastructure, such as networks, virtual machines, load balancers, and connection topologies. Just as the same source code always generates the same binary, an IaC model generates the same environment every time it deploys.
IaC is a key DevOps practice and a component of continuous delivery. With IaC, DevOps teams can work together with a unified set of practices and tools to deliver applications and their supporting infrastructure rapidly and reliably at scale.https://learn.microsoft.com/en-us/devops/deliver/what-is-infrastructure-as-code
So we can see that Infrastructure as Code is a core part of what makes modern software delivery, enabling teams to own and deploy their own infrastructure can cut all sorts of key metrics. If you look for example at the Google DORA metrics:
- Deployment Frequency—How often an organization successfully releases to production
- Lead Time for Changes—The amount of time it takes a commit to get into production
- Change Failure Rate—The percentage of deployments causing a failure in production
- Time to Restore Service—How long it takes an organization to recover from a failure in production
All of these metrics can be directly affected by the ability of teams to own their infrastructure as well as their software. Infrastructure as Code doesn’t necessarily mean you improve these KPIs and measures automatically, but it does put the responsibility into the team’s hands directly.