There are many automation tools out there that businesses can use to automate and utilize Infrastructure as Code (IaC), Application deployments, container setup, etc. They bring different abilities and flavor. Choosing the right tool for your organization is worth taking a step back and look at which may serve your particular needs the best.
Two main types of tools, Configuration Management and Provisioning tools. The high level difference is that Configuration Management tools are specialized on delivering deployments and changes to application on already existing servers, Provisioning tools are specialized on delivering the setup of infrastructure and servers themselves. This is of course simplified as there are plenty of overlap between the two types.
The most known Configuration Management tools are Ansible, Chef, Puppet and SaltStack. For Provisioning tools it is Terraform. We have also AWS CloudFormation, Azure Resource Manager, and Google Cloud Deployment Manager; which are all tools specific for one Cloud Vendor.
Mutable vs Immutable
Mutable means it can be changed, immutable means it cannot be changed after creation.
Configuration tools, like Puppet, Chef, Ansible, and SaltStack are mutable. If you where to update a program in a Kubernetes container system, these tools would utilize the OS update function and update the program that is requested to be updated.
Provisioning tools, like Terraform, are immutable, which means that the only way to change the configuration is to deploy a new version with the new configuration. In the Kubernetes Container example this means Terraform would delete existing container and deploy a new one with updated configuration.
The Mutable systems will create a uniqueness of the servers over time, which may make troubleshooting harder. This is also called drift – however the biggest creator of drift on a system is anything that is unique like manual work on that exact system.
Configuration tools, like Puppet and Ansible, will default to mutable – meaning if a running program needs. It is however possible to force configuration tools to be immutable, but it isn’t the unique approach for these tools.
Procedural vs Declarative
Ansible and Chef are procedural, which requires a code that specifies a step, by step approach to achieve the desired state.
Terraform, SaltStack, CloudFormation, and Puppet are Declarative, meaning you specify how the end state is to be.
If we want to deploy 3 servers we need to specify for both procedural and declarative languages that we want to deploy 3 servers. The difference occurs if we want to deploy 2 more servers, total of 5. For the procedural languages we need to write a new file where we specify two more servers as we already have 3. So we need to know the amount we have and add scripts for what we want to add.
For the Declarative language that reads the file as the end state we need to change the number from 3 to 5, when we deploy it will check the environment see that there are 3 running and then deploy 2 more. The difference in these two approaches become more obvious if we decide to extend the capacity of the 5 servers, from say (Azure type Standard_B1s to Standard_B2s). In the Declarative languages we will use a file that describes the desired state, so we will change the VM size on the initial file. It will check the existing servers, remove them and redeploy 5 new servers in the correct size. For the Procedural languages, we need a step by step description, so first a file to delete the existing servers and then a new to deploy them, and we still need to keep track of what we have outside the code.
This is not saying that either is better than the other, however the advantage with a Declarative language is that we do not have to write as much code to achieve infrastructure state as we have to do with the Procedural languages.
Master-less vs Master
Configuration Management tools require as a default a master server for storing the state of your infrastructure and distributing updates. The tools have a client that connects to the master server and then the master server pushes the changes to the clients. The master server can also be configured to verify the configuration of the clients and if changes have occurred, due to manual changes, change the server back to default configuration.
Having a master provides the advantage that there is one single place to see the status of the infrastructure and to managed changes from. With many tools it also follows a website where we can do many of the changes.
Drawbacks of a Master server is among other, the need for maintenance, it adds extra infrastructure and extra security challenges. We have at least one extra server to update, patch, back up, and scale. In the security aspect we have to ensure the communication between Master Server and agents/clients happen secure, and keep extra awareness on extra open ports.
Some of the Configuration Management tools also work in a Master-less configuration, typically the agent/client would pull the changes from Source Control.
Provisioning Tools are master-less in the sense that you do not have to operate a master, they utilize APIs that are provided by vendors like AWS and Azure. Which ensures that there is no extra systems needed to maintain.
Agentless vs Agent
Chef, Puppet and SaltStack require us to install agent software on each of the servers we want to configure. The agent is a background process that keeps contact with the Master Server. Running agents gives the drawback of having to maintain the agent software and ensure it keeps in sync with the Master Server. Based upon if we have configured the agents to pull from the Master or the Master to push changes to the clients there are open ports that require awareness and monitoring. Provisioning of the agent software has to be handled, when our tool of choice have created the server the agent needs to be installed and configured so it can receive packages from the Master Server.
Ansible and Terraform don’t require any agent to be installed. Mostly any agents, if needed, are already taken care of by the cloud vendor as part of their infrastructure. When using the tools the you only have to worry about the execution of the code and the vendors agent executes the code. For Ansible the Servers need to run the SSH service, which most servers run by default.
Bleeding edge vs maturity
Automation tools pop up all the time. The more younger they are the more bleeding edge, where the developers are still trying to figure out where they want to go with the product. The disadvantage here is that the tool can change in functionality and compatibility from version to version. When a new version is released portions of the code may have to be rewritten.
Puppet 2005, Chef 2009, CloudFormation 2011, SaltStack 2011, Ansible 2012, and Terraform 2014
Other considerations
Other consideration could be things like popularity in the marked and size of the communities. As these are Open Source tools the popularity will add more commercial interest to the tool, which will ensure that there is skill to hire in the job marked either as consulting or employees. The size of the community says something about the viability of the product to continue deliver improvements to the platform.
Which tool to choose
Each Enterprise is served having a strategy of where to focus the effort. The mindset of automation takes time to adapt and the languages take time to master. The automation of infrastructure or system configuration takes time, it requires a lot of focus and investment for the Enterprise. Selecting the right tools are important, making the wrong choices will give problems down the road.
I hope that this high level look at the attributes will help in selecting the technology to go forward with.