Infrastructure as Code (IaC) is the management of your infrastructure through machine readable definition files, much like source code for an application.
The infrastructure that you manage through IaC could relate to networks, virtual machines, load balancers, monitoring, containers, databases, storage and much more.
The principle of using IaC is to bring a repeatable and consistent method to deploying your environment every time you need it.
In this article we’ll explore the benefits of using infrastructure as code, common methods and the tools you can use to deploy your infrastructure.
Benefits of Infrastructure as Code
There are a lot of benefits to using IaC within your business. There are benefits both to your engineers and the business as a whole.
Decreased Risk
Provisioning your infrastructure manually, by hand is risky. Unintentional mistakes could be made, a tick box is left unchecked changing the entire configuration.
Knowledge on how to deploy the infrastructure might be lost if someone in the company leaves.
By representing your infrastructure as blocks of code you can derisk the deployment.
Blocks of code are generally less error-prone.
It is best practice to store your IaC in a source code repository, and this gives you history, changes and context as to what the code does.
Security is an important factor today, especially when deploying within public cloud platforms like Microsoft Azure, GCP or AWS.
You need to ensure anything deployed is adhering to your organisation's security policies.
When deploying manually again there is the chance of mistakes happening, deploying through IaC means that those mistakes aren’t going to happen.
Building your IaC to adhere to security policies and needs of the organisation means they are then whenever or whoever deploys that infrastructure.
Consistency & faster iterations
When you manually deploy your infrastructure it can take a lot of time, to ensure that everything is configured how it should be.
It can be a slow process that holds up other areas within the IT department moving forward.
If you store your infrastructure configuration as IaC then you can ensure that every time it is deployed it is the same. No tick boxes are left unchecked or a setting missed.
It will be the same regardless of who deploys it.
Traditionally the Operations team within an IT department deploy the infrastructure introducing IaC to your department can mean that more people can deploy the infrastructure. This can allow for faster iterations across the department.
Cost & Speed
As stated earlier, manually deploying your infrastructure can be time consuming.
By introducing IaC to deploy your infrastructure you are speeding the process up, and freeing up your resources to do other tasks.
Which ultimately means you are saving money, your team can effectively hit a button to deploy the infrastructure and then go off to work on other projects or tasks while the system carries out the deployment.
The speed at which you can deploy infrastructure via IaC is markedly different than when you do it manually. Speeding up the deployment means you can better react to changes and requests.
Infrastructure as Code and DevOps
Writing templates that define how to configure, build and construct your infrastructure is a great move forward. But you also need to look at automating it and moving away from the manual deployments. Especially if your developers are already automating their software code with a DevOps CI/CD pipeline.
Having your software code and infrastructure code automated and version controlled will really give you the benefits that we talked about above and much more.
Infrastructure as Code Methods
When we are writing or talking about IaC it is important to understand that there are two types of methods available and their differences. The two methods are declarative and imperative.
With a declarative language it defines the desired state of the target. It describes the intended goal that has to be reached.
With an imperative language you define the specific commands that need to be executed to achieve the desired state.
Let’s use a real world example to explain this in simple terms. If you were going to bake a cake the imperative recipe would be:
- Turn your oven on and preheat at 190°C
- Add your eggs, sugar, butter, flour to a large bowl and mix well.
- Once mixed, pour the batter evenly into a round cake tin.
- Bake for 30 minutes
- Remove the cake from the oven and let it cool for 5 minutes.
- Remove the cake from the tin and enjoy.
If we were to bake a cake following a declarative recipe it would be:
- Preheat the oven at 190°C
- Mix ingredients in a bowl.
- Put the cake batter in the oven and bake for 30minutes.
- Once baked, remove from the oven.
- Enjoy.
The imperative way gives you explicit instructions, like “pour the batter evenly”. In the declarative way we are really just told what should be happening, with the goal being a cooked cake.
Back in the tech world imperative is great for the deploy and forget model of deploying infrastructure. If you are looking for a more agile or changing environment then declarative might be more appropriate.
But it really comes down to the needs of your organisation, skills of staff and lots more besides.
Infrastructure as Code Tools
There are alot of tools out there you can utilise to define your infrastructure and environment into code. Chef, Puppet, Azure Bicep, AWS CloudFormation, Pulumi, Terraform and Ansible are just some of them that are available. Let’s take a look at each of these.
Chef
Progress Chef (formerly Chef) is an open source tool that can run on any cloud platform as well as Windows or Linux operating systems.
The culinary terminology is used throughout their tooling as you use cookbooks and recipes to not only deploy your environments but also configure your systems.
Chef has been around since early 2009 and has a large back catalogue of templates or recipes you can pull on.
You don’t have to start from scratch.
Chef uses Ruby DSL as its syntax so does require either existing knowledge or the ability to learn to make the most of it.
The other issue with Chef is that it requires infrastructure to run on, which can amount to a significant cost and also add in some additional management overhead.
Puppet
Puppet is a declarative IaC tool that is used to deploy and manage your system configuration.
Like Chef, Puppet requires an infrastructure to run it on with agents being deployed to servers you are deploying and managing.
Puppet is a tool that is heavily used for on-premises deployments, and as such there is a large support community out there to help and provide examples.
Azure Bicep
Azure Bicep is a declarative language that will help you deploy your Azure resources. I've also heard Azure Bicep described as a Infrastructure as Code (IaC) tool. \
Azure Bicep is an evolution from Azure Resource Manager (ARM) templates that we've had for many years. You don't need any prior knowledge of ARM templates to get started with Azure Bicep.
Azure Bicep can only deploy to Azure, for those working in multi cloud environments it can’t be used to deploy to other environments. One of the benefits of using Azure Bicep though is, because it is a first party product when any new features or products are released you can immediately use Bicep to deploy or configure them. You don’t have to wait for that integration to come along, which is one of the downfalls of third party provider tools.
AWS CloudFormation
AWS CloudFormation is a tool that can help you create or manage your resources within AWS in a programmatic way using Infrastructure as Code (IaC).
It can help you replicate your environment easily within a few clicks.
You can declare the resources that you need within your CloudFormation template. They will be created in the right order.
A CloudFormation template can either be YAML or JSON.
Similar to Azure Bicep, AWS CloudFormation can only be used within the AWS cloud environment so can’t be used to deploy resources to other environments.
Pulumi
Pulumi is another declarative IaC tool. Pulumi is slightly different than other tools, it allows you to write your templates in either TypeScript, JavaScript, Python, Go or C#.
Meaning if your team already has coding skills in one of these languages they can easily adopt Pulumi.
It can be a tricky tool to learn if you don’t have any experience of those languages though, and can make adoption slow.
Pulumi works with any of the cloud providers, giving those within multi cloud environments a lot of flexibility.
Terraform
Terraform is an open source IaC tool that has been created by HashiCorp.
Terraform is able to deploy resources to all the major cloud providers as well as the ability to deploy to some on-premises solutions such as Hyper-V and VMware.
Because Terraform can deploy to so many solutions lots of people are choosing this as the IaC tool.
They learn the syntax for the tool then can use that knowledge to deploy resources to where they need to.
While you can’t take a Terraform template that deploys Azure resources and apply it to AWS you can take the knowledge you have on how to create templates to create the correct one for AWS, etc.
Terraform relies on plugins called providers to be able to interact with the cloud providers or other APIs.
Each provider adds resource types or features to Terraform. Because Terraform is a third party tool it can be slow for providers to be released when new features or products are released by cloud providers.
Ansible
Ansible is one of the imperative IaC tools on the market that helps to not only deploy your resources but also configure them.
Ansible relies heavily on YAML and Python for its syntax.
Ansible is agentless so there is a decreased maintenance cost to using this as your tool of choice.
Conclusion
Adopting IaC is crucial to engineers and organisations in this ever changing IT world.
You might have to learn something new, you might have to change your way of working as an engineer, but it’s the way deploying infrastructure is moving.
It really will help to break down barriers, bottlenecks and information silos within your department.
And then moving forward and integrating your IaC with DevOps principles will streamline processes and workflows even further.
Don’t delay, start your infrastructure as code learning journey today!
Top comments (1)
A very well written article! I just want to mention that Pulumi's YAML support is in preview. pulumi.com/docs/intro/languages/yaml/