Why Infrastructure as Code should be more widely adopted in agile IT teams

By Aled Davies

A padlocked and chained metal gate positioned behind text that reads: IAC HAS A BIG PROBLEM WITH ACCESSIBILITY' followed by the words 'Aled Davies' 'Co-Founder of Codeherent'

Problems in technology have been solved with technology for a long time.

This is a cycle of abstracting complexity. 

I’d like to launch the Codeherent blog by taking a look at a few of the problems that technology has tackled – in an order many of those already working in DevOps will be familiar with. I also want to highlight the critical complexities associated with cloud and infrastructure management.  

The speed problem

Man pedalling on a black racing bike in Sky sponsored clothing. The bike is racing along a road with the words 'The speed problem' in white in front of him.

The root of a lot of what we see in technology today is a direct result of businesses searching for solutions to what I’d like to call ‘ the speed problem’. 

Businesses typically want to release software faster whilst simultaneously reducing errors and bugs. 

Thankfully, the speed problem was solved by the adoption of agile, fast release cycles and continuous delivery, better testing practices, and a fail fast mentality. The speed problem was solved and businesses could respond quickly to changes required.

The Ops problem

Or could they? There was now a bottleneck. IT operations couldn’t keep pace. Let’s call this ‘the ops problem.’ 

IT Infrastructure has been changing from on-premise – large teams, slow to scale, not cost-effective – to cloud for a long time now. When cloud came along, the paradigm shifted to allow smaller teams to be able to request on-demand infrastructure. This solved parts but not all of the ops problem. The siloing of knowledge and maintenance, in the form of configuration drift, remained. This meant that businesses were unable to respond quickly in a dynamic environment.

DevOps gave us speed and supreme IT operations

DevOps sought to solve the speed problem and the ops problem. AWS describe DevOps as “the combination of cultural philosophies, practices, and tools that increases an organisation’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organisations using traditional software development and infrastructure management processes. This speed enables organisations to better serve their customers and compete more effectively in the market.” 

Multi-cloud gave us choice

DevOps addressed the speed problem and the ops problem and businesses could finally turn their attention to better optimising their use of cloud. A range of cloud providers became more readily available for businesses to choose from. A ‘one size fits all’ strategy for cloud is becoming a thing of the past. Companies are opting instead to use two, three, or more providers, across a mix of public and private platforms, as their preferred strategy for different tasks across the organisation.

Blurred spread of colour cards positioned behind the text 'This is multi-cloud' and a sub title '...this is choice'

This is multi-cloud. 

Multi-cloud means that businesses avoid the vulnerability of ‘single vendor lock-in’. More importantly, multi-cloud offers benefits including greater agility and cost efficiency to manage workloads in different environments to match requirements. It opens up new opportunities for innovation and accelerates the roll-out of new services to customers. 

The multi-cloud problem

Maintaining all these different services all at once, across different cloud providers, is extremely complex. It is so complex that we encounter the siloing of knowledge across an organisation and we begin to slow solution delivery down again. This is ‘the multi-cloud problem.’ 

Are cloud management tools the answer to it all?

When it comes to managing multiple cloud providers, the first tools that may spring to mind are actually produced by the cloud providers themselves.

AWS for example provides a CLI (Command Line Interface) and SDK’s with Microsoft Azure and GCP who also provide their own tools to help manage infrastructure. As you might guess, these tools typically don’t make it easier to manage a multi-cloud environment; they often cannot communicate with each other easily.

Other tools commonly used are known as Configuration Management (CM) tools such as AnsiblePuppetSaltStack, and Chef. They do the heavy lifting to help when configuring one or many server instances (e.g., installation of packages, starting of services, installing scripts or config files on the instance). The scripts they use can also be designed to provision infrastructure – especially when combined with the cloud providers CLI’s and SDK’s – but this requires writing custom scripts which can get very complex across larger organisations and are unlikely to be accessible to the whole DevOps team.

So how are organisations managing their multi-cloud at scale?

Modern tools including HashiCorp’s TerraformAWS’s CloudFormation, and Azure Resource Manager let teams define the state of infrastructure using code, this approach is commonly referred to as Infrastructure as Code (IaC). These are designed specifically for provisioning infrastructure and as a result, organisations are adding this as a step before configuration management to replace the custom scripts that have been written to a more homogeneous format.

For a truly multi-cloud solution, Terraform is quickly becoming the go-to tool for provisioning multi-cloud systems. Using a single coding language, it can be used for building, changing, and versioning infrastructure safely and efficiently across a diverse range of services (a full list is available here).


Blurred image of a frustrated man in glasses positioned behind large white writing that says: 'BUT WHAT IF YOU DON'T UNDERSTAND TERRAFORM?"

Enter: the accessibility problem

But what if you can’t understand the code to be able to read and understand Terraform scripts? 

Before IaC and multi-cloud, organisations traditionally had Ops teams and System Architects taking charge of the provisioning of infrastructure.

But what if an organisation wants to fully embrace DevOps and give development teams ubiquitous access to build the infrastructure alongside the code?

Expecting swathes of employees and teams in a business to learn how to code IaC with Terraform is absurd. It doesn’t scale. Let’s call this ‘the accessibility problem.’  

The teams writing the Terraform are wanting to build infrastructure as consumable Modules (Terraform Modules) which other users inside the company can use to allow development teams to quickly decide on and build out the infrastructure they need. Because making Terraform accessible to a breadth of teams in an organisation is almost impossible, the potential for Terraform to solve the multi-cloud problem – and with it, the speed and ops problems – is partly going to waste.

Codeherent makes IaC accessible

To solve their ‘problems’ using IaC through Terraform, businesses must first solve the accessibility problem. 

Terraform code needs to be made accessible to the whole organisation – whether its for engineers to create infrastructure, teams to review infrastructure, or operations to monitor and optimise infrastructure. 

It is for these reasons that I co-founded Codeherent and why we’re committed to increasing the accessibility of IaC for businesses.