Sooner or later, any DevOps is faced with the need to learn and use Configuration Management and Remote Execution. Configuration Management Tools in DevOps play a big role.

Working with infrastructure according to the concept of Infrastructure as Code using such systems is a necessary hygienic minimum to ensure a systematic approach in IT operations.

The main idea of these tools is to ensure the traceability of changes, repeatability and consistency, convenience, simultaneity and mass, and simply the quality of IT operations.

We at Microdevops could not provide a high quality of service without the mandatory use of DevOps Configuration Management. Actually, we do almost everything with it, here are just the simplest examples:

• OS settings.
• Application deployment.
• Create users.
• Firewall management.
• Bringing up services.
• Well, and Configuration Management Services.

If we talk about the Top-10 DevOps Configuration Management Tools, in general, the following tools can be noted:

• HashiCorp Terraform is the de facto standard today for deploying and configuring infrastructure in the clouds, we use it in Microdevops.
• Ansible is also almost a standard for Configuration Management, but we do not use it, as our choice at one time fell on…
• Salt (or SaltStack) – similar to Ansible (also YAML, also Python), although a peer to Ansible but less popular, at the same time more functional: events, zeromq, agent. Most of our systematic knowledge is concentrated in Salt https://github.com/microdevops-com/microdevops-formula. We use it not every day, but every minute :).
• CFEngine – they write that it is popular, but we have never seen it in reality and have not tried it.
• Chef and Puppet are classics for Configuration Management. Very functional and mature, but inferior to Ansible and Salt in simplicity, clarity and lightweightness, we do not use them.
• Pulumi – is often mentioned as an alternative to Terraform and praised, but we did not use it, too radical approach.
• AWS CloudFormation, Azure ARM or Bicep, Google Cloud Deployment Manager – vendor locked tools for native use in AWS, Azure, GCP, if required.

Bonus: the above tools cannot be used normally without one more:

• Git + GitLab/GitHub/… – since configuration manifests are actually text files yaml/json/tf/etc. After all, it is necessary to store them as code (that is why it is Infrastructure as Code), and the code must be stored in git.

In addition to the aforementioned formula with reusable Microdevops code, we also have a client repository template https://github.com/microdevops-com/salt-project-template, which helps to generate and update very quickly (the template can be reused on an already used repository! ) projects for clients. Moreover, our accounting system https://github.com/microdevops-com/accounting deals with the automatic templating of client repositories based on the template, adding there the lists of accounting servers, tariffs, etc. So it actually performs automatic configuration of the Configuration Management code itself.

In conclusion, we can say that, generally, it does not matter which Config Management Tool you chose. Because under the condition that:

• Configuration Tools are used systematically.
• You accumulate knowledge in the chosen tool (or several).
• Have enough expertise to quickly implement ideas and tasks with code without manual operations and those debts

your DevOps will be good enough!