When starting with Infrastructure-as-Code you have loads of choices to make. Tool selection for infrastructure deployment is an important one. In my experience each company/team has different opinions and experiences which can lead to great conversations.
This post will assist you with decision making, I will sum up different tools, methods, strategies with pros & cons and questions you can ask yourself and the team.
The choices come down to preferences, knowledge, skillsets and which strategy you define.
Tools
For this post the main focus is on the following tools: Terraform, Ansible, AWS CloudFormation, Bicep and ARM Templates.
Methods
Also known as programming paradigms, is an approach (style or way) a programming language uses.
Below are two methods which are important when writing Infrastructure-as-Code.
Declarative | Imperative |
|---|---|
You describe what the outcome should be (desired state of the target) without specifying control flow. | Specific commands that must be executed in specific order (step-by-step) and all commands need to run to achieve desired state. |
System executes what needs to happen to achieve desired state (like adding resources and configuration) | |
Iac tool figures out what needs to be done. | |
Example
“Can you get me a cab when I go home?”
“Figure out what time I go home, where I live, call the cab, specify how late the cab should arrive, specify pick-up place and specify destination.”
Pros
Declarative | Imperative |
|---|---|
Great for updating infrastructure and/or making changes to it | Gives you more control |
Works great in AGILE organizations | |
Easier to understand | |
Reusable |
Cons
Declarative | Imperative |
|---|---|
Can be slower | Not very reusable often used for ‘Deploy and forget’ |
Provisioning and Configuration Management
Configuration Management tools (Ansible, Puppet, Chef) means that they are designed manage and install software on existing server. At some degree they can also provision, but this is not why they were built.
Provisioning tools like Terrafom, Bicep, CloudFormation and ARM templates are designed to provision. At some degree they can also be used for configuration management.
Immutable and mutable Infrastructure
When a new software release should be installed on servers, immutable tools will run the update on each existing server and the changes will be applied in-place. Applying more and more updates over time will result in a unique installation path per server. This often leads to ‘configuration drift’.
When a new software release should be in place on servers, mutable tools will deploy new machines based on an image with only the latest version installed.
Cloud strategies (approach)
The Cloud strategy (approach) is a side-step in this blog, but can be useful with decision making regarding tool selection.
Cloud Agnostic is when a tool, application, platform can run within any cloud (infrastructure) and can be moved to/from different cloud providers.
Cloud Native is when a tool, application, service or platform is specifically designed to run on services on a specific (cloud)platform.
Another term that is used for referring to applications in the cloud, is “Cloud Enabled” (which is not an approach but worth mentioning). Cloud Enabled applications are applications which originated on-premise and have been refactored to be enabled in the cloud (often IaaS combined with cloud services).
Pros
Cloud Agnostic | Cloud Native |
|---|---|
No vendor lock-in, so not locked into a single vendor | You can take advantage of best innovative services of cloud providers (applications can run more efficiently), which can provide more value to customers |
Portability | Native applications/services use the provider’s API for its security and compliance features which can make them more secure |
Ability to maximize redundancies (reduce downtime risk) | Native services can be cheaper |
Easily scalable | |
Easily maintained |
Cons
Cloud Agnostic | Cloud Native |
|---|---|
You can’t take advantage of best innovative services of cloud providers, which can slow down your service to customers | Vendor lock-in |
More complex solutions,
for example to build high available architecture (disadvantage for engineering team)
| Less redundant |
Because of the complex solutions, the transition to the cloud can take more time | |
Generally higher costs | |
In general using cloud native services with your applications, the application is more flexible for migrating to another solution. Also some applications can have more support or performance in specific (cloud) solutions.
There is no reason to pick one or the other, but you can ask yourself:
- “How often will I actually be moving from one cloud or on-premise solution to another?”
- “Do I want to be Cloud Agnostic with all my applications, services or platform? Or specific ones?”
So combining approaches can also work.
Example
With a Cloud Agnostic approach applied only to tooling, you have the benefit of managing multiple clouds with one tool and still have the benefit of the cloud native solutions. The team(s) only have to learn one tool for managing different cloud and on-premise solutions.
Make sure that the team is aware which approach should be applied and when. And for unique situations a clear decision making process should be in place.
Tool comparison
Attribute | ARM Templates | Bicep | AWS CloudFormation | Terraform | Ansible |
|---|---|---|---|---|---|
Native | Azure native | Azure native | AWS native | – | – |
Cloud Agnostic | – | – | – | Yes
Multi Cloud | Yes
Multi Cloud |
On-prem (hybrid) | – | – | – | Yes | Yes |
Method (Language) | Declarative | Declarative | Declarative | Declarative | Imperative |
Category | Provisioning | Provisioning | Provisioning | Provisioning | Configuration Management |
Approach | Immutable infrastructure | Immutable infrastructure | Immutable infrastructure | Immutable infrastructure | Mutable infrastructure |
Code validation | what-if operation |
Before deploying an Azure Resource Manager template (ARM template), you can preview the changes that will happen | what-if operation |
Before deploying a Bicep file, you can preview the changes that will happen | Change sets |
Change sets allow you to preview how proposed changes to a stack might impact your running resources | Built-in Code validation, formatting and feature to show what is going to be deployed.
Run a ‘plan’ to see what is going to change before they change | Validating tasks |
Modules | Linked templates | Yes | Yes | Yes | Yes |
State management | Queries directly from Azure | Queries directly from Azure | Yes, with stacks | Yes, with state file | No, obtains facts by using REST API |
Learning | First you need to learn JSON.
ARM can be difficult to learn.
Troubleshooting can be difficult.
| Much simpler than ARM for writing templates. | You need to learn JSON and YML | HCL (Hashicorp Configuration Language), is based on Golang, which is one of the most easily learned IaC languages. | You need to learn JSON and YML |
Open Source | Yes | Yes | Yes | Yes | Yes |
Enterprise support | Yes | Yes | Yes | Yes | No |
Pros
In general with Cloud Agnostic tools (Terrafom, Ansible, etc.) you have the advantage to deploy to multiple cloud solutions.
Cons
In general Cloud Agnostic tools have the disadvantage of not being able to utilize newest services right away. Depending on the community and suppliers the new services will be added as soon as possible.
You can ask yourself:
· “Do I want to be the first with newest services, what are the disadvantages?”
When there is no state management (like with Ansible), this means that there is no dependency tracking. Tasks will be executed sequentially,
In general with Cloud Native tools, these can only be used for deployments in one specific cloud (Azure when using Bicep and ARM templates, AWS when using CloudFormation).
Summary
Choosing an Infrastructure-as-Code deployment tool can be challenging, be thoughtful about it. Don’t be afraid to make a decision, even though afterwards you find out that another tool better fits your needs.
Like with learning to code, you can see this as training a muscle, the more often you do this the better you get. If you get the essence of IaC, you know that tooling only supports you.
In my experience I started out with on-premise deployments with PowerShell, afterwards with Ansible (AWX), Azure CLI for on-premise and Azure deployments, later on with Terraform and now I am also discovering Bicep. I prefer Terraform.
The most effort (for me) was moving from traditional deployments to automated deployments and after getting the hang of that, learning other tooling was less of an effort.
Code examples
