Why would you pick Salt over Ansible
August 01, 2016

Why would you pick Salt over Ansible

Anonymous | TrustRadius Reviewer
Score 8 out of 10
Vetted Review
Verified User

Software Version

SaltStack (legacy)

Overall Satisfaction with VMware vRealize Automation, with SaltStack Config

We've used SaltStack throughout the whole engineering team of our company for provisioning of both AWS instances and baremetal servers. Previously we've been using Fabric for this, but it has become unusable once we've grew beyond 25 servers, and our environment become heterogeneous. Engineers couldn't keep track of what's happening in the server farm any more, and SaltStack and it's declarative language allowed us to bring up instances to desired state in a quick and reliable way.
  • Rich, powerful DSL
  • Highly scalable – fast, parallel deployment to dozens of nodes
  • Strong community
  • Steep learning curve
  • No sandbox, dry run, or execution plan mode. It's hard to iterate quickly during development, and quite easy to break things during development.
  • Copying huge amount of small files is slow and suboptimal — make sure to package your software into tarball/dpkg/your favorite package format if you need to copy it to the instance.
  • Engineering spends less time on Ops
  • Engineering has more time to build features
  • Server farm is more stable, which means better uptime and happier customer, as well as less pages for engineers.
Ansible and Salt have emerged around the same time, and are pretty close.

Ansible pros:
- seems to have a better community these days.
- it is simpler to setup.
- DSL is considered to be simpler.

Salt pros:
- It is better for auto scaling environment.
- DSL might not be as intuitive, but it's well-designed, very powerful and consistent.
Amazon Elastic Compute Cloud (EC2), Zendesk, GitHub
If you need to frequently set up or update a large amount of server instances, Salt and Ansible are probably the two most popular options these days. The key difference is probably the master-minion model of Salt, where minions can pull the state from master, while Ansible emphasizes "push" model (there's Ansible-pull, but it seems to be an afterthought).

In practice, this means with Salt it's trivial to build an AMI which will pull state from master on startup and bring the new instance into service. You can use that instance with AutoScaling group, and voila — you have a scalable cluster on full auto.