4 ms·

Chef did not make a clean transition into the immutable world. Chef Client was great for persistent infrastructure, but the options got dicier once we started t

Chef did not make a clean transition into the immutable world. Chef Client was great for persistent infrastructure, but the options got dicier once we started talking about pre-provisioned infrastructure like image building: 1. Chef Solo (how I last used it when attempting this), which felt intentionally hobbled. All you needed was one poorly-behaved cookbook that called `search` and the bets were off. 2. Chef Zero, which was unnecessarily complicated for being Chef Solo that wasn't intentionally hobbled, so much so that I kept using Solo for awhile after its deprecation. 3. Chef Client, against a Chef Server that was run either for your other persistent infrastructure, or just to have a place to put the cookbooks. Heaven forbid you weren't cleaning up all of those dynamically-created nodes, though... I still think Chef's Ruby DSL is much more natural than the YAML manifests used by Ansible, and the ability to integrate at the source level with custom Ruby code is a killer feature as soon as any complexity enters the mix. But I almost certainly would not be using Chef in a greenfield deployment these days.

nunez 1y ago
Right. If Chef had adopted agentless earlier (or, rather, made Chef Solo less confusing to use), Ansible would not have eaten its lunch like it did.
nyrikki 1y ago
While I agree with a lot of what you said. In my experience, it was the need for orchestration that killed it but we are probably using different definitions of "immutable", where in Chef context I think of it as the infrastructure. For me the killer feature of ansible for me was the ability to gate based on remote state, which really was incompatible with the foundational engineering choices that were almost ideal for its original target. When you were upgrading rabbitmq, postgres, etc... the view from other cluster nodes was critical, not the local view. Both chef and puppets tried to graft on what they called orchestration, but was really just batch jobs. Immutable infrastructure was fairly easy IMHO with chef if your architectural quantum was a machine, but not for situations where that quantum was a cluster, especially with data that needed to persist like with Cassandra etc...

nunez 1y ago

Right. If Chef had adopted agentless earlier (or, rather, made Chef Solo less confusing to use), Ansible would not have eaten its lunch like it did.

nyrikki 1y ago

While I agree with a lot of what you said. In my experience, it was the need for orchestration that killed it but we are probably using different definitions of "immutable", where in Chef context I think of it as the infrastructure. For me the killer feature of ansible for me was the ability to gate based on remote state, which really was incompatible with the foundational engineering choices that were almost ideal for its original target. When you were upgrading rabbitmq, postgres, etc... the view from other cluster nodes was critical, not the local view. Both chef and puppets tried to graft on what they called orchestration, but was really just batch jobs. Immutable infrastructure was fairly easy IMHO with chef if your architectural quantum was a machine, but not for situations where that quantum was a cluster, especially with data that needed to persist like with Cassandra etc...