Infrastructure as Code or IaC is becoming a staple for configuring, deploying and maintaining infrastructure and service configuration in the cloud.

Both of the large Hyperscalers, AWS and Azure support their own version of IaC. AWS has CloudFormation, and Azure has ARM (Azure Resource Manager).

Then there is the ever popular open source Terraform from Hashicorp.

AWS released CloudFormation on 25th February 2011, Azure released Azure Resource Manager in April 2014 around the same time that Hashicorp started hacking on Terraform.

This post isn’t about which solution is best, because there are many good things and bad things about all of them and each have different reasons for why you might want to use one over the other. In more recent times people have created abstraction layers such as Serverless Application Framework (previously known as JAWS), CFNDSL, Troposphere, CDK and many others.

Regardless of how you write and even to the extent of how you deploy and manage your IaC there are key important reasons why it makes sense for everyone to use IaC regardless of whether you are managing long running resources (often referred to as pets) or faster moving environments (often referred to as cattle).

Change Management

Anyone who’s worked in the IT industry for any length of time has had to deal with Change Management in some format. ITIL is the classic and often the standard that is adopted by Enterprises, but there are many more possible options, from logging issues in something like Footprints, Bugzilla or FogBugz and building releases from a group of those issues to modern approaches relying on systems such as Jira and DevOps Continuous Integration and Continuous Deliver (or Deployment) type processes.

When considering change management it is important to understand what has changed within a particular window, whether that is minutes, hours, days, weeks, months or years, the more accurate the picture of what has changed overtime and when can help understand problems and assist in finding contributing factors. Of course there is an added bonus of meeting compliance obligations, but we don’t these systems and processes just to meet compliance, do we 😉?

When using IaC you would defintely want to peer that up with your favourite Version Control System, and the most popular and the one which today probably has the most market share is Git. Peer this with a centralised system such as Gitlab, Github, Bitbucket or Azure DevOps and you have a method of showing changes all the way through the life of the code.

Further, you would want to integrate your centralised Git system with your favourite problem, change and/or task/issue systems, e.g. Jira and ServiceNow. When making changes you can reference your ticket IDs so that a correlation between the originally raised request or incident or whatever triggered the change.

Lastly, if you include raising changes with your pull-request/peer review process, you can remove all human interaction, raise changes automatically and depending on a set of rules, automatically approve or seek approval based on your process and workflow and then automatically deploy the change either immediately or within a change window.

Not only do you have a full list of all changes ever made, you can also have a fully integrated and automated change system that removes all human intervention that can include full testing steps in non-prod systems, automated security validation, and automatic deployment improving not only the quality of changes but also shifting security left.

Consistent, Fast and Repeatable Deployments

IaC also provides a way to build commonly used patterns and blueprints. Within any large organisation or service provide you need to have the ability to deploy environments that meet required standards and provide automated monitoring, patching, anti-malware and backups all ready to go so they don’t need to be considered as an after thought and often not found until audits happen.

Once you have defined patterns you can also then deploy these in a tool that provides easy access to everyone via tools such as AWS Service Catalog or Service Catalog provided through your favourite ITSM tool such as ServiceNow.

This allows you to put the power of strongly consistent deployments in the hands of everyone, freeing up your core team to focus on providing better value and faster delivery of services that help the business grow.

Scaling Automation

Now that you are deploying across your entire organisation in a repeatable fashion and you are tracking all changes in a consistent and detailed manner you now have the ability to make large wholesale changes because every environment is in a known state.

This makes it possible to deploy changes such as ELB Cipher upgrades, EBS changes, compliance and audit reporting, monitoring changes amongst many other changes that would be easily deployed and reviewed across the entire eco-system that you look after.

Conclusion

It doesn’t really matter waht IaC approach you use, the key here is to use it, and use it everywhere. IaC solves many of those compliance requirements as well as allowing your teams and business to deploy and make changes with confidence and with speed.