
DevOps tools review for DataCenter automation: Ansible-StackStorm-SaltStack - anyrekmi
https://medium.com/@anthonypjshaw/ansible-v-s-salt-saltstack-v-s-stackstorm-3d8f57149368
======
lobster_johnson
I've used Puppet, Ansible and Salt. While they get the job done, they all suck
in a myriad of ways. They're slow, brittle, have bad documentation (I'm
probably being cynical, but Puppet, Ansible and Salt all seem to have been
created as consulting companies first and software second; they _thrive_ on
the inadequacy of their documentation).

One problem with the "post-Puppet/Chef" generation of tools is the over-
reliance of templatized YAML as a DSL. Salt's use of YAML is particularly
egregrious. For all the criticisms of Puppet's custom language, at least it's
a _language_ , with proper types, a consistent syntax, and a good measure of
strictness. I like YAML as configuration file language, but it's _terrible_
for DSLs.

~~~
BurritoAlPastor
I'm surprised to see this particular criticism applied across the board –
Puppet's documentation is one of my favorite things about it.

~~~
lobster_johnson
Admittedly, Puppet's documentation is better than it used to be; I've been
using it since 1.x, and it used to be a lot worse. However, it's still a bit
tedious to browse through.

The weakest part has always finding reference documentation — that is, things
like this [1]. Everything is a bit buried and scattered. At least they finally
have a complete list of configuration settings [2] now, which used to be a
huge pain.

[1]
[https://docs.puppet.com/puppet/4.10/types/file.html](https://docs.puppet.com/puppet/4.10/types/file.html)

[2]
[https://docs.puppet.com/puppet/4.10/configuration.html](https://docs.puppet.com/puppet/4.10/configuration.html)

------
alrededorr
"If you’re going to skip to the end and see which I declared the winner- you
will be disappointed. Consider your requirements and try more than 1 of these
products." \--- truer words have not been spoken

------
napsterbr
Regardless of tools, I see two features as essential: agentless clients +
programmable dsl. As far as I know, no such tool exists (would love to be
proven wrong).

Ansible relies on SSH only, which is pretty much a must on 99,9% servers
anyway, but its language (and philosophy) is purely declarative. At the moment
you need anything generic, abstracted into functions, you are in trouble.
(Believe me, you don't want to be hacking stuff into Yaml, it's a mess).

Chef is the opposite: you have access to a Turing complete language, but you
need an overly complex server architecture along with running agents on all
nodes.

Merge Ansible's ssh client with Chef's programmable dsl and you probably have
something huge there.

~~~
gtmanfred
Have you tried salt-ssh?

You can use the other renderers in there as well, you don't have to just use
yaml.

[https://docs.saltstack.com/en/latest/ref/renderers/all/salt....](https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.pydsl.html)

------
acd
I have used Puppet, Ansible, Saltstack and Chef. In the beggining using puppet
was annoying because you had to explicitly declare all dependencies or Puppet
would do things in the wrong order. This has since the latest versions of
Puppet been fixed.

Ansible is good but it has already been forked to Stonic, which for me is a
sign of disagreement in the community.

A lot of the management tools tends to have their config agents crashing so
you need to baby sit your agents instead of just configuring your servers. I
tend to use Puppet, Ansible standalone pulling the configuration templates via
git that avoids the crashing agents issue.

------
mosesschwartz
I'm a little bit surprised to see StackStorm directly compared to Ansible and
SaltStack. There's certainly overlap in capabilities, but in my mental model
of the space Ansible and Salt are primarily configuration management, while
StackStorm focuses on event-based orchestration.

In my environment we're using both Salt and StackStorm very effectively. Salt
for CM and StackStorm as a platform for building automated, event-driven
tools. They're really very complementary, especially since both are Python-
based.

~~~
mirceaulinic
The overlap of capabilities is between StackStorm and Salt -- the later has
many orchestration capabilities. For event driven ops it can even be used
alone. I don't want to say that one is better than the other, but this
comparison does not surprise me at all.

As a friend (big Ansible fan otherwise) would say: "Ansible is just a
glorified bash script; nothing more, nothing else". Without making it a bad
product, Ansible is that one limited to CM only.

~~~
lnkmails
StackStorm developer here and I definitely am writing this as an engineer. We
in fact use ansible for our own infra where we deploy a bunch of StackStorm
nodes. Our CI CD pipeline, staging tests and packages promotion all are driven
via StackStorm workflows. We also spin new environments on every merge commit
to master (results in OS packages which are then deployed to a box) and have
built sophisticated automation with StackStorm workflows. Every time I use
Ansible, I cannot get over the fact that it is bash in Python. Our API driven
approach, chatops, declarative when needed with workflows and ability to be
imperative (write python code) for actions etc are things I really love. We
are learning from all of the other tools ourselves but I also hope we are
setting trends in workflow orchestration.

------
mdekkers
I have done extensive work with both Salt and Stackstorm, and am surprised
they don't see wider uptake, especially Stackstorm. Stackstorm is a brilliant
system.

------
dzimine
Puppet vs Salt/Ansible is old story, they're compared as applied to config
management.

Anthony is bringing a different angle here: how Salt / Ansible / StackStorm
compare as event driven frameworks, applied to all-purpose automation, aka
GLUE. Puppet/Chef aren't even playing.

Do you see this relevant? Or do you think "Salt beacons, who cares?" Why?

------
nunez
So this isn't a complete picture for complete datacenter automation. you need
something that handles server turnup from the minute it's racked and creating
images for those servers.

cobbler used to be the go-to tool for provisioning bare metal but rackhd seems
to be the new contender in this space. that + packer + terraform + CM = 100%
automated DCops

