First of all Ansible is extremely capable. And this is not a new debate on what is best, just try all and stick with one.

Second, I used Ansible for a good time, move to Salt is not a easy thing, and time consuming. But you know, your first kiss is never as good as it can get with practice. So when we change tools, we are more mature and get things quicker. I'm glad Ansible introduce me to the world of infrastructure as code and DevOps, but lets talk about why I made that decision.

Short speaking:

• No inventory management
• Master/Agent architecture
• The ability to react to events
• Git repository integration

Ansible inventory's are cumbersome at scale, I guess 5 to 10 servers, if they change constantly, you start getting boring and looking for ways to automate this. I found that when start preparing nodes for kubernetes installation, I did many fucking times.

One way to minimize this is Terraform Inventory for Ansible

I found that SaltStack accept keys is much more pleasant to use. Combined with cloud-init (if you can) is a breeze.

The main reason of discordance is the Master/Agent vs Agentless architecture. This is where you should evaluate more careful comparing this tools.

Agentless is easy to get up and running, you just need SSH and python on the target machine, which most linux distributions bring on by default. It makes the experience really great to start.

SaltStack has agentless operation mode, but is not the first class citizen here. It encourages you to use Master/Agent.

In a master agent architecture has the advantage of being fast, really fast. Another advantage is scalability and resiliency with multiple levels of masters and arrangement for distributed load and redundancy.

Salt stack uses Zeromq message system as a central part (you don't even see) to how is able to perform fast and on scale. Another advantage is that events can be capture and actions (stack's) can be applied. This is a big plus in my opinion, besides de fact I'm not using it (yet).

For instance, I will start security and common provisions (states) as soon as a new system is added to the fleet.

Another advantage that catch my attention is that the execution is made on the master. It forces you to not have powerful keys on admin's laptops, that means in the case of compromise you better of securing one thing instead off a number of moving things. You can do that on Ansible by forcing the keys to be on server, but is not a good workflow (git commit, git pull, ssh, ansible command), which leads to my final point.

Git repository integration - The master can watch for git commits and refresh it's files. That way is ready for you to apply the state manually, or automatically. To automate this you should be careful and probably have a QA environment and production branch, approval revision and this kind of things, because you know, shit happens, but automatic shit is way worse :-)

Disadvantages:

• Salt add nomenclatures (pillar, stack, minion, grains). Once you get used to it, things start making sense, but is not a pleasant first experience.
• An agent adds memory and processor footprint. Is small, unless you are dealing with embedded or really restricted hardware. Is negligible for must servers and virtual machines.
• It takes more time to grasp. This is the second time I try salt. My first trial I drop very quickly because of this onboard experience that fells more to fully day devops engineers. As result I keep ansible for while, it did the job.
• Ordering: declarative, explicit, definition and lexicographical optionals with precedence. Ansible order just makes more sense.
• Repetitive. If you need to make sure some components are installed in a couple of different states, reuse that is not as straightforward as in Ansible, I get myself rewriting and duplicating things more often.
• You need a new server. That adds a little in the cost.

I have yet to migrate all ansible playbooks to salt, I'm taking a as need approach and doing it slow. As a result I will probably find more disadvantages and advantages, is just normal.

The monitoring capabilities of salt is something I plan to investigate. Could it replace Prometheus?

To conclude. Salt stack is part of my workflow now, I think I will take more benefit than loss using it.

This is the kind of tool that is not easy replaceable, if you are happy with Ansible, by all means keep and master it.

I recommend you look no further than Salt and Ansible, Why? It's time and energy consuming to test and use configuration tools of this kind, and once you start there is a high dependency on its code, in better words your infrastructure becomes code. This two can be considered a new generation.