In a previous blog around Azure Governance we spoke about standardisation of configuration and deployment. This leads us into another topic – Infrastructure as Code (IaC).

What is Infrastructure as Code?

As soon as you hear the word code, people tend to think it’s about developers and IT infrastructure people tend to get very nervous, but they shouldn’t.

Infrastructure as Code brings the benefits of automation, such as quicker, easier, and more reliable execution to the deployment, provisioning and configuration of servers and other infrastructure.

Below, we’ve created a brief list of benefits of IaC:

  1. Better and easier compliance:
    • Configuration consistency and certainty – remove human error, improve standardisation, compliance
    • Ability to safely manage, deploy and track changes – spin up environments automatically and easily, reduced access to production environments for individuals
  2. Reduced risks when people leave:
    • Should a person leave the company, the institutional knowledge doesn’t completely go with them, configurations are documented in code and always up to date
  3. Ability to quickly and easily deploy / re-deploy new environments or regions to:
    • Respond to customer demands
    • Respond to business demands
    • Respond to incidents
  4. Save time and money

Sticking within the Microsoft ecosystem, this is typically done using ARM Templates deployed from Azure DevOps. Of course, there are many 3rd party solutions you can use as well.

ARM Templates are a way to declare the objects, types, names and configuration of resources that you want deploying, via a JSON file. They are flexible in that you can deploy a single resource or multiple different resources from within the same template (beware of complex templates!).

These templates are stored in Azure DevOps in a repository (usually shortened to repo).  Once there you can apply source control to your templates, restrict who has access, who can make and approve changes to them and what changes have been made. 

In order to deploy the templates, a pipeline is created. This specifies what templates to deploy, in what order and where to deploy them to. These pipelines can be triggered to deploy manually, or automatically based on an update being added to one of the templates. You can also add approval gates so that templates cannot be deployed without the correct authority or without following the correct process.

The above is relatively high level and skips over some parts, but hopefully gives you a feel for what Infrastructure as Code is all about. If you’re interested to learn more, please send us a message at hello@walkerscott.co – we love to talk Microsoft technology!