Infrastructure as Code (IaC)

Infrastructure as Code is an approach for the provisioning and maintenance of infrastructure. Having a configuration file(s) which describes your infrastructure can provide many benefits, such as self-documentation of what you have, gives simplicity to the deployment and configuration and can improve your speed to market.

Tools that are available can provide agility when it comes to the cloud provider you use, and your ability to quickly move to another if required, or harness a hybrid approach and utilise the best of different cloud providers. This can require little work with some tools as they have their own DSL.

Infrastructure is managed as a whole thus helping recover from failures or disastrous situations without manually having to identify the current state.

Characteristics of IaC tools

There are a plethora of tools available, some open sourced, actively maintained by a community of enthusiasts and core contributors. Others are closed source and maintained by the creators.

It is difficult at first to choose which tool to use in the long run, as this is fairly recent concept. None of the companies have reached a level of maturity that could differentiate them from their competitors.

This being said, you then have to evaluate each tool and identify each of their characteristics and decide which meets your priorities.

Below is a diagram which identifies the main tools that provide orchestration and configuration management, or to some degree, both.


Given this quick overview of the main competitors, it is easier to identify which tool to use based on priorities.


Open source is often a collaborative, open environment where anyone can contribute to a project where the code is publicly available to view. Closed source is the exact opposite, where access to the code requires you to be part of the company creating the product.


This is what platforms the products can support. Some can also work outside of a cloud environment, i.e. on premise infrastructure such as VMWare.


There are two categories of tools when it comes to infrastructure as code, both can be suitable for the provisioning and orchestration of infrastructure depending on your requirements.

Configuration management tools are designed to install and manage software on existing servers.

Orchestration tools are designed to provision the servers themselves, leaving the job of configuring those servers to other tools.

These two categories are not mutually exclusive, as most configuration management tools can do some degree of provisioning and most orchestration tools can do some degree of configuration management. But the focus on configuration management or orchestration means that some of the tools are going to be a better fit for certain types of tasks.


Infrastructure can be either mutable or immutable. The difference between them being mutable can be modified post creation and immutable will be destroyed and provisioned with the new modifications.


When comparing procedural vs declarative, we are essentially comparing two mindsets. With procedural languages, we usually define steps that influence the state, opposed to declarative languages where the state to be reached defines the steps that should be taken.


The tool's architecture determines the components that are required to get everything provisioned and deployed. Some tools will require you to install clients on the target servers in order to deploy configurations to it, and others will simply SSH onto the box.

Which tech is best for us?

Now let's put all these concepts together and make an educated decision when it comes to IaC for Zuto.

The difference between open source and closed source doesn't really make any difference when choosing the right tool, considering they all offer free tiers with upgrade options. It's a good thing to be able to look into the inner workings of the tools we use with open source, in the case we need to extend a feature or patch a bug quickly, however, a proper level of support usually comes with enterprise options.

If having mobility and flexibility is a requirement, then we definitely need to look into platform agnostic solutions. Being locked in with a vendor is a scenario we would like to avoid going forward in order to allow the business to be able to react quickly to market changes.

This is why we've ruled out CloudFormation since it is used only with AWS.

At Zuto, we are also concerned with long term maintenance, ease of management and consistency. We might feel more comfortable using a language that describes the end state of our infrastructure. This would allow us to focus more of our energy on figuring out what we need, instead of debugging how to get there.

A declarative language will also help us reduce the time required to recover from disaster scenarios, and reduce the possibility of errors when spinning up infrastructure because the result obtained is always predefined. Having to decide the steps to take depending on each possible scenario with a procedural language could prove to be quite challenging the more complex the state is.

This is why we've ruled out Chef and Ansible as they use a procedural language.

Another important aspect to keep in mind is immutability. We definitely want to prevent snowflake servers that require special configuration beyond that covered by automated deployment scripts, making it easier to debug any issues due to knowing everything that composes the environment of our infrastructure.

If you have multiple apps running on a single server, you might not want to redeploy all those apps after rebuilding a server, this is where a mutable infrastructure, and configuration management, may better suit your requirements.

This is why we believe immutability is a good choice for us, thus ruling out all but Terraform.

Co-authored by David Silva

Nathan Smith

An engineer with a passion for simplicity.


Subscribe to Zuto Tech Blog

Get the latest posts delivered right to your inbox.

or subscribe via RSS with Feedly!