Infra as Code in the Enterprise⌗

As someone who has done infrastructure provisioning and automation for better parts of my career, I am constantly surprised at how ill informed a lot of people working in traditional enterprise IT is on the topic.

When an organisation moves workloads to one of the major clouds, too frequently people fall into the trap of thinking that the console is there as the primary means of setting up resources. Unfortunately the cloud providers in many cases build up under this assumption, as there is a distinct advantage in showing how “easy” it is to use the UI, over complicating efforts by introducing Infrastructure as Code (IaC).

However while the barrier to entry might seem low for the first couple of simple VMs you set up, what inevitably happens is that organic growth of the ClickOps (resources created by clicking in the UI) system will very soon create a lot of issues.

Reproducibility⌗

I have heard a number of horror stories about critical ClickOps infrastructure that was inadvertently deleted or destructively altered, causing real production incidents. The perceived ease of use of the UI is often an illusion, where the UI tries to hide away important complexity.

When a team instead of using ClickOps writes a Terraform/Pulumi/Cloudformation config and deploys it, most such changes will both be preventible (see CICD below) and also, the resource in question can also be reproduced from the code.

CI/CD process for IaC⌗

Most modern IaC pipelines have introduced a set of quality and security checks that will prevent most common mistakes, ensure policies are not broken and that consistent configuration is kept. Without defining the infra as code, the options for setting up these quality gates will be severely limited, and much more intrusive policy management will be required (automated checks of running resources etc.)

Change history⌗

Using IaC with a sensible version control system enables the best kind of change history, again this is hard or impossible to replicate in a ClickOps environment.

IaC as documentation⌗

When a cloud environment is defined sensibly via Infra as Code, that doubles as documentation for the setup. Without this, any resource created needs to be manually documented, a process which is prone to both (human) error and gaps in what is documented.

What now?⌗

I hope more traditional enterprise IT engineers will see the IaC light, as more and more enterprises lift workloads from old outdated on-premise systems to cloud environments. However the general immaturity around the topic makes me worry..