Ask HN: How do people feel about Puppet?
2 comments
You’ve answered your own question really! Technologies like containers where configurations and so on should be immutable removes a lot of the need for tools like Puppet/Chef, so much so that I’d argue an app needing a complex puppet/chef/anisble/whatever stack to deploy can sometimes be a code smell sign now.
That said, I’m sure there is going to be lots of customers such as in enterprise with badly written complex old apps that are a nightmare to deploy looking to use puppet and similar for a while yet.
My own experience is Ansible has typically had a shorter learning curve for developers than chef or puppet, but I last used puppet in 2014ish. Puppet, Chef especially, both in my opinion require you to become expert in chef and puppet too much to use well.
That said, I’m sure there is going to be lots of customers such as in enterprise with badly written complex old apps that are a nightmare to deploy looking to use puppet and similar for a while yet.
My own experience is Ansible has typically had a shorter learning curve for developers than chef or puppet, but I last used puppet in 2014ish. Puppet, Chef especially, both in my opinion require you to become expert in chef and puppet too much to use well.
I’m familiar with Chef, Salt, and Ansible, but I believe the following will apply to Puppet as well: the configuration management tools that I’m familiar with work by essentially merging many complex state changes. These state changes typically come from multiple providers, who are not necessarily aware of each other’s work.
Differences in configuration management software come down primarily to how users define those changes, merge behavior, and how the changes are applied. Furthermore, the prior state of systems (on which changes are applied) can be quite difficult to predict, and the configuration software is expected to just work regardless.
I compare configuration management to implementing a multi-master database, hard to reason about, easy to screw up.
Containers (as already mentioned in the comments) are the preferable alternative whenever they are an applicable replacement. In the case of Docker, each container definition starts with a known input, applies changes sequentially and produces an output. These definitions can be chained together. I compare their usage to function composition, easy to reason about, hard to screw up.
The fact that you’re talking about configuration management at all implies you’re managing long-running servers and not using a PaaS solution. IMO this is a big maintenance headache, and is to be avoided when possible.
All this is to say: there are some times you’ll need to run servers yourself, there are certain tasks that will require configuration management, but they should be used as little as possible; favor containers and PaaS whenever you can. There are differences between configuration management solutions, but those differences are dwarfed by the advantages of just not using them at all.
Differences in configuration management software come down primarily to how users define those changes, merge behavior, and how the changes are applied. Furthermore, the prior state of systems (on which changes are applied) can be quite difficult to predict, and the configuration software is expected to just work regardless.
I compare configuration management to implementing a multi-master database, hard to reason about, easy to screw up.
Containers (as already mentioned in the comments) are the preferable alternative whenever they are an applicable replacement. In the case of Docker, each container definition starts with a known input, applies changes sequentially and produces an output. These definitions can be chained together. I compare their usage to function composition, easy to reason about, hard to screw up.
The fact that you’re talking about configuration management at all implies you’re managing long-running servers and not using a PaaS solution. IMO this is a big maintenance headache, and is to be avoided when possible.
All this is to say: there are some times you’ll need to run servers yourself, there are certain tasks that will require configuration management, but they should be used as little as possible; favor containers and PaaS whenever you can. There are differences between configuration management solutions, but those differences are dwarfed by the advantages of just not using them at all.
Puppet's competitors like Chef, Ansible, and Saltstack have all been bought up by larger companies so the channel and partner influence they have is massive over Puppet.
They tend to release and EOL products too from what I understand. Some friends in the industry mention that the tech is so hard to use compared to Ansible.
I have been offered a job as a senior SE there. They are going for an IPO this year which makes it an interesting proposition.
Could anyone share your thoughts on Puppet?