Which Configuration Management Tool would you pick Chef, Puppet, Ansible, or SaltStack?

We always hear about different management tools that companies are confused about, and wondering which one is more efficient to use for their development environments and operations. Will, bottom line every day we are getting into confusing choices especially when it comes to management and efficiency, especially that we are getting into a point to pick between 4+ tools, successful, ready and needed. As Software DevOps and Architectures, we always look at the requirements, but for other teams, they are always looking for the results.

Let's start with why we need them in our development cycle?

Mass deployment, test/production environments differences, one source of truth for logs and changes, for example, a business that has more than 3 VMs or instances for production purposes only, 5 VMs for testing, and there's a configuration change within the infrastructure code that should go to all of the instances or the system wouldn't work, ex. new PHP library Ldap or any other library that needed for the base code to functionally work, and we need to update all instances together. 

Solution 1) we do that manually by updating all of them per codes, so if the base code exist on Test only we need to update all VMs for test only unless this library or change would not make a problem for production, which in that case we can update the prod instances before releasing the Test version of the code to production.

Cons: this is a manual process that would maybe produce more problems and bugs than expected.

Solution 2) Using docker images, and in this case, every time we are updating the container's libraries, we should rebuild all instances in full every release.

Cons: Longer time of deployment, which can be useful for businesses that they don't work 24/7. On another hand, this solution would work in specific clouds and environments and would work perfectly in case of on-premise servers which uses docker as a base of the host.

Solution 3) Command lines or Shell scripts, which we can create a simple shell script file that we implement in our base code, and make it run for every instance every time we have a new change.

Cons: writing the shell script from scratch, which may need more expertise and would have more maintenance by time. Another con, shell script is a codebase only no UI to control.

Solution 4*) Use a Management tool to update your instances from one place, ex. Chef, Puppet, Ansible and more. These options depending on the business host would be available with the minimum effort of scripting and would handle the situation as expected to add/modify or remove infrastructure codes with a 99.9% accuracy. 

Cons: Maybe this would lead to learning a new Language (Ruby/YAML) depends on which one the business needs to use.

In my opinion, none of these options is required to use, however, I picked solution 4 because of the efficient and constant deployment would be. It's all about the results and maintenance after implementing any of them, I will explain it more within this article. but, Before we move on, just remember all four tools are going to be Automated Configuration Management Enables Consistent Configurations at Large/Small Scales, with some small differences.

One of the most popular questions is "What does it mean pull or push based functionality?

To explain it with examples let's start with DevOps tools Puppet and Chef are pull-based but Ansible is push-based. How? 

1- Pull-based: Agents on the servers periodically check for the configuration information from the central server or Master

2- Push-based: Central server pushes the configuration information to targets or clients instead, which gives you the control when the changes are made on servers.

Simple Pull as trees giving water to their branches and leaves by the request of the leaves, while Push as watering the trees using a hose.

Let's start talking about these tools.

1- Chef

The Chef software is used to streamline the task of configuring & maintaining a company's servers and can integrate with cloud-based platforms such as Rackspace, Microsoft Azure[4] and Amazon Elastic Compute Cloud to automatically provision and configure new machines.

Master-Agent Architecture - Chef server runs on the master machine and Chef clients run as agents on each client machine, so one source push service.

Learning -If the business doesn't have Ruby engineers, this would be a tricky point, while Chef using Ruby as the main Language. But again, Chef got a lot of tutorials around to learn.

Operation Systems - Works on Linux and Unix but Chef client and workstation can be on windows too.

Pros

- Strong community supported by toolsbook, and market place

- Well development reporting mechanism   

- Easy after install     

Cons

- New Language is required Strong Ruby

2- Puppet

Puppet usually follows a client-server architecture. The client is known as an agent and the server is known as the master. For testing and simple configuration, it can also be used as a stand-alone application run from the command line.

Master-Agent Architecture - Puppet server runs on the master machine and Puppet clients run as an agent on each client machine as Chef.

Learning - It's not easy to learn while it's using a specific language named Puppet DSL, and non-immediate remote execution.

Operation Systems - The Master server would work with Linux and Unix, but Puppet Agents can support Windows as well.

Pros

- Strong community supported by Puppet Labs

- Well development reporting mechanism         

Cons

- New Language is required Puppet DSL

3- Ansible

Ansible is an open-source software provisioning, configuration management, and application-deployment tool. It runs on many Unix-like systems and can configure both Unix-like systems as well as Microsoft Windows.

Master-Node - It has only a master running on the server machine, but no agent running on the client's machines. Which we call it to pull mechanism, no special setup, but as performance side, it's using the same agent machine or client machine performance, so dependable.

Learning - easy to learn while using YAML (Python).

Operation Systems - Supports Windows machines, but Ansible server has to be on Linux or Linux.

Pros

- The core of Ansible, playbooks, are written in YAML

- The agent need not be installed on the systems that require configurations

- Ansible works well with environments where the focus is on getting the servers up and running quickly

Cons

- Performance speed is often less than other tools

- YAML is not as powerful as Ruby

4- SaltStack

is Python-based, open-source software for event-driven IT automation, remote task execution, and configuration management. Supporting the "Infrastructure as Code" approach to data center system and network deployment and management, configuration automation, SecOps orchestration, vulnerability remediation, and hybrid cloud control.

Master-Agent Architecture - Server called master and clients are called minions which run as agents in client machines. Similar to Chef and Puppet Architect.

Learning - easy to learn while using YAML (Python).

Operation Systems - Minions work on Windows, Linux, and Unix but The master Agent doesn't work on Windows machine.

Pros

- SaltStack is Python-based while the instructions are written in YAML and it's DSL

- Simple once it's setup

- Good reporting mechanism, with easy operation views 

- SaltStack CLI based tool that automates configuration management and remote execution.

Cons

- Setup can be a little tricky

- A less developed tool, as it's using relatively new web UI compared to other tools

All four tools have the same high availability and run with different specifications, for example, Puppet has multi-master architecture, if the active master went down, then the other master would take the place, similar to Chef when there's a failure in the primary server, there's a backup server to take the place of the primary server, similar to Ansible, run with single active node, called the master primary instance, if the primary goes down, there's a secondary instance to take it place, again similar to SaltStack, but the difference that SALTSTACK multiple masters configured if one is down the second would take place. So, in general, all of these solutions would work perfectly to different businesses, it's all about the knowledge and simplicities.

Summary:

The final decision is your business requirements, needs, scales, and expectations, nothing called better or smarter, it's all about the requirements and knowledge. I mentioned scales, because if your business is not a big scale online business, which means no need to have more than one or two instances, then I would prefer to use a simpler deployment process than using any of these tools.

Feel free to leave comments below.