Progress Chef vs. Salt Project

Chef is a very nice tool for establishing and maintaining a consistent configuration across a range of servers. In addition, Automate allows the continued monitoring and maintenance of servers so they don't drift from established standards. Overall, it deals very well with complex systems. Chef is slightly less applicable for a micro-services approach where the servers are replicated from a simple and known starting point.

Incentivized

Managing heterogeneous environments of large numbers of nodes, especially nodes which may need sudden changes (security updates, for instance), or frequent replacement, is a strength for Saltstack. Simplicity is not a strength for Saltstack. In a homogenous environment (all CentOS 7, for example, with no Debian or Windows) I might recommend using Ansible instead - it is less flexible and granular, but simpler to configure.

Incentivized

• Chef is very easy to learn. Written in ruby, Chef code is high enough level for non-ruby coders to get a general idea of what the script is doing.
• Chef can be a one stop shop for writing code, testing infrastructure, and deployment of applications.
• The Chef support team is very helpful in their auto manager support as well as active support in their Slack channels from development engineers & architects.

Incentivized

• A superb remote execution framework! SaltStack allows us to easily program numerous functions on top of it. For example, we developed a fast parallel asynchronous deployment tool that handles all software deployment, including interdependent service management.
• Configuration management is now easy. We take advantage of this to automate (in tandem with AWS tools) the stand-up of all servers and services. It is also relatively easy to create new configuration management states for software not yet supported by the community (e.g. Grafana).
• Flexibility. Numerous small utilities have been built which simply wrap around SaltStack to allow tedious tasks to become easy.

Incentivized

• One main concern with Chef is the maintainability of Chef master.
• The Chef-client should be installed on every node we want to do any automation.
• It is mostly Ruby and there's a learning curve. Need to understand the fundamentals of Chef very throughly to play around with attributes, templates etc etc.
• The Chef-client agent needs to be run on the nodes frequently to update the details of it state to master. And also to index the nodes based on tags.

Incentivized

• Managing network hardware should be more native and easy
• SaltStack should buffer jobs and, when a client returns, make sure it is executed proberly
• SaltStack should provide basic pillar and states structures to help get newbies started

Incentivized

The suite of tools is very powerful. The ability to create custom modules allows for unlimited potential for managing all aspects of a system. However, there is pretty significant learning curve with the toolset. It currently takes approx 3-4 months for new engineers to feel comfortable with our implementation

Incentivized

It loads quick enough for basically all our systems. Because we have this for local dev environments, speed isn't really a big issue here. Yes, depending on the system, sometimes it does take a relatively long time, but it's not an issue for me. One thing that is annoying is that if I want to make a small change to a cookbook and re-run the Chef client, I can't just make the change in the cache and run it. I have to do the whole process of updating the server.

Incentivized

Support for Chef is easily available for fee or through the open source community as most the issues you will face will have been addressed through the Chef developer community forums. The documentation for Chef is moderate to great and easily readable.

Incentivized

We haven't had to spend a lot of time talking to support, and we've only had one issue, which, when dealing with other vendors is actually not that bad of an experience.

Chef is the more developer-oriented of the three main tools in this space. It has a steeper learning curve as a result but it allows you to do more. Puppet seems to be more geared towards automated the management of the operating system. Ansible is an excellent tool but requires you to allow SSH connectivity into all of your instances.

Incentivized

I've used shell scripts over ssh, custom in-house deployment tools, Chef, and SaltStack. I've evaluated Ansible, but I was never happy with performance over SSH. Chef's loose configuration data model and lack of philosophy and conventions around use makes it difficult for a team to share responsibility for configuration code. Needing to use additional tools to do orchestration for cross-host/agent dependency relationships made me look for more. SaltStack, while not as mature when I first tried it, impressed me with its speed and elegant design

Incentivized

• We can deploy tens to hundreds of servers in a small amount of time.
• We can grow our infrastructure very quickly with limited resources adjusting to customer demand as soon as the need arises.
• We are able to automate many of the mundane tasks that used to occupy the time of our engineers allowing us to focus on more critical tasks.

Incentivized

• SaltStack has reduced the time it takes to deploy new machines for us 10-fold.
• It is much easier for us to maintain compliance with industry standards with SaltStack.
• No negative impacts!

Incentivized