Yet Another Puppet vs Chef vs Ansible vs Salt Topic

Whenever there is a configuration management discussion, there is always a debate that spins around "Puppet vs Chef vs Ansible vs SaltStack" topic (ok CFEngine people, don't be pissed, i will talk about it too).

In general these discussions are generally bias fueled and leads to nothing but a dead end. And people think that in this arena there is a clear winner.

From my perspective there are no winners here, there are just nuance differences and your team's choices. In this article i will try to be fair as much as possible and i will list these nuance difference clearly. Do keep in mind that these are my views, not facts...Its merely a list of positives and negatives depending on my judgement...

One key thing that i want to tell straight, is that GitHub contributions or StackOverflow/ServerFault stats are not a key element to the outcome of this comparison.
An example is that unlike Puppet and Chef, Ansible and SaltStack are born in GitHub so they will naturally have more contributors and i also have a feeling python plays a role too :)
So the articles that emphasis on these points as important kpis should be overlooked...

Lets talk about the nuance differences;

Puppet



Pros:

  • Has the biggest community.
  • Arguably carries the most mature Windows support.
  • Puppet is well established, and you have some quality paid support options if you want to go that route.
  • Richness of knowledge provided in Forge.

Cons:

  • Puppet comes with it's own DSL called PuppetScript. And it is unique in its own form. I judge this as a clear con because i fail to see the advantage this provides over pure code OR a very simplified solution like YAML. Basically this adds X amount of time for the team members to spend learning on something that doesn't translate to any other place.
  • Puppet's error reporting has been always a pain point and one of the reasons people switch.


Chef



Pros:

  • Very thin DSL, resulting in an almost pure ruby experience, a definite plus in my opinion... The closest to the "infrastructure as code", when complexity increases it doesn't lose readability.
  • Tested at the biggest of scales, Facebook.
  • Chef Server management UI is well done.
  • Very rich marketplace of cookbooks

Cons:

  • Not as easy to pick up as YAML.
  • Chef may pose the most difficult learning curve to administrators who lack significant programming experience.
  • Documentation is sometimes vague.
  • Needed some training materials a few months ago, you have to enter your details to receive them... I feel like this is a bad place to form a mailing list..


Ansible



Pros:

  • Basically automates configuration via pushing commands through SSH so no agents are required in managed clients.
  • The easiest to pick up due to both YAML & Agentless architecture - Very active community

Cons:

  • For advanced operations it uses Jinja2 template language for python, for complex infrastructure code this is used a lot and it makes it much less readable and more complex.
  • Because of the agentless architecture, management on bigger scales are painful.
  • Immature Windows support.


Salt



Pros:

  • Salt message bus is a winner[0].
  • Supports multiple architectures, push/pull master/masterless etc.
  • Being the newest and the latest has its own advantages(observe others, don't make their mistake.)
  • Potentially the scalability is very high.

Cons:

  • For advanced operations it uses Jinja2 template language for python, for complex infrastructure code this is used a lot and it makes it much less readable and complex.
  • Compared to the others, the web ui is a big question mark.
  • Reporting capabilities is a question mark.
  • Windows support is a question mark.

Conclusion


There, these are the nuance difference from solely in my point of view. One thing you should keep in mind that which tool you choose to use doesn't matter if you aren't using anything. Automation is always > no automation. You will benefit from any of it...

So as far as personal taste goes i should input some of my thoughts;

If you are already invested in Puppet, you should know that migrating to another tool does not really provide much value over your loss on production time. But if i were to start a new project, I believe i wouldn't pick Puppet :) I don't like PuppetScript and i cannot reason to spend time to learn that dialect where there are many more options now.(except of course if i need to maintain a puppet codebase, or a business requirement) I think that the time to go for Puppet is if you want to maintain Windows machines, as i believe they have the most mature solution to this.

Currently i use Chef and i like it the most out of the other options, the thin dsl was a really good call, the supermarket is really rich and the community is very helping. But of course there are few negative sides as i listed above.

Ansible is a really good call for the teams that lack the programming experience and has need to manage infrastructure. Out of all the options Ansible is the least complex one. From start to the "hey we are using it in prod now" range is the shortest out of all.

Personally i feel like Salt had a really big advantage by being the late comer to the game and its a good option out of the four, but it would have been really epic if they could have replicated what chef did with its very thin dsl. I feel like if Salt did something similar in Python rather than YAML & Jinja2(I have been notified that Salt actually supports this now), it would have been magnificent. Still its fine, but i really find jinja2 unnecessary. Its basically the side effect of laziness of sys-admins for not learning the basics of a programming language as useful as python/ruby... Because if you can write programs in Python or Ruby, there is absolutely no reason to manage your infrastructure in YAML & Jinja2 combination.


But CFEngine?



Ok, so the thing with CFEngine, and the reason people doesn't add it to these comparisons is not because it can't compete with these solutions but because it kind of lost steam(community support) within the transition from 2.x versions to 3.x rewrite.

I never used CFEngine actively but i have some knowledge on the topic. What happened was that before 3.0 there were many bad parts to CFEngine and the community was giving feedback to this topic than the late rewrite came (3.0) but around that time a lot of people migrated to other communities. As of now, CFEngine is a very capable solution that i also observe in some companies that utilizes it, its just that the community is not there anymore...

Disclaimer

I am not related to any of these Companies/Products

References


[0] http://docs.saltstack.com/en/latest/topics/event/index.htmlFF