CINC Is Not Chef
cinc.sh
cinc.sh
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.
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...
It is very well thoughout and simple to design and run.
I've been using it a bit, and I like it. However, it is a lot more like programming in Python (rather than defining configuration) when you do anything outside the normal rails.
That's not a bad thing, but it is a different thing.
Still testing it more, and my needs are different than everyone else's, but so far I wouldn't say to anyone who already uses Chef, Ansible, Salt, etc. they could switch to Pyinfra, because the 'core' tool for automation is similar, but the ecosystem is altogether different.
I am moving some of my personal projects over to Pyinfra though, but for now mostly to flesh out my own understanding of it—my main stuff is all still Ansible.
Now we're stuck with what I call the "DevOps ball of mud". I gotta learn 15 different yaml formats alongside the nuances of every hyperscaler and micro cloud. Like seriously it's 2025 and we still gotta deal with stateful bullshit and a bunch of unoptimized docker containers flung all over the place. It feels like nobody has solved the application runtime stateful egg and we're all just dancing to the dark gods of Docker, Kubernetes, and Helm in hopes that our blood sacrifices make the engines go for another month.
Full Disclosure: I worked at Chef for 5 years
In fact every time I’ve migrated to Ansible (each time from Puppet), we’ve built the infrastructure so Ansible pulled its configuration.
A systemd service runs ansible-pull about 2 minutes after boot. It does its thing.
It has some annoyances, but it works fine. I don't think about it anymore. The git repo is the source of truth.
SSH is inadequate because this process should be much slower than the life of anyone's terminal window. You could approximate it with cronjob pulls if each node's schedule is a little offset from the previous. But you probably also want different rollout schedules available for different scenarios.
I use Ansible personally when I'm dealing with a server or two. I use Puppet professionally when I am dealing with tens of thousands of servers and trying to keep them all in some kind of unity.
It also has tons of advantages, notably around scale (Ansible id very slow when working with thousands of machines) and ensuring that there is no drift. Also e.g. SaltStack (RIP) has cool features such as reactor to react to events on the machine which are only possible because there's an agent
And I think that's where the comment you're responding to is coming from. Once you've experienced Docker/K8s and, to a lesser extent, IaC tools like Terraform, it's hard to see yourself ever going back to tools like Chef in the same way that tools like Chef made it hard to see going back to a world where we configured servers manually.
It seems to me that this is kind of like abstraction levels in programming. If you can use a high level language with lots of powerful tools, you do. But some people have to live in the world of C or even assembly, because (as James Mickens said) you can't just place a Lisp book on top of an x86 chip and hope it learns about lambda calculus by osmosis. I view IaC tools in the same way: if you can use Terraform or Docker, great! But someone has to use lower level tools to provide the environment in which those things exist. And that's why people shouldn't look at Chef (or other similar tools) as outdated, any more than assembly is outdated just because Lisp exists. They still very much have a strong use case that won't ever go away.
vi: 1976
BSD UNIX: 1978
x86 instruction set: 1978
UNIX System V R4.2 1983
Linux: 1991.
Kids these days.
After using it for a few years, accumulated enough quirks to significantly diminish my initial enthusiasm. The concurrency gotchas, the utter lack of debugging and profiling tools, the weak management of today's most common deployment models (e.g. Docker/containers and cloud services)...it's not "good" by 2025 standards.
I'm sure enterprises still do use it. But they also still use RPG, PL/I, and IMS. So...
What "simple" tool is left anymore for me to create my immutable AMIs that aren't bound by some license?
Fabric is a favourite for this kind of thing (although I'm configuring VMs at runtime instead of building AMIs)
Of note, this is not affiliated with Chef itself [1], but looks like Chef has blessed it [2]
[1] https://cinc.sh/disclaimers/ [2] https://cinc.sh/blog/cinc_client_is_live/
It's basically the same model as Red Hat. Except Chef never had the market penetration and brand recognition as a trusted source that Red Hat has.
Signed, someone who worked for Chef for almost 13 years.
(Only then did I originally post my question to Hackernews. I can read. The info just is not there.)
These are just my anecdotes, for sure, but (also anecdotal) I rarely hear of other "ops" type people using Chef, and most of the ones I know never got more than just their feet wet with Chef (the SaltStack beta was out early enough to avoid Chef).
> For the stragglers not yet primarily on Kubernetes and Terraform
In my experience - you see all three of these, k8s, TF and chef working in the same cluster. But, I'm only an anecdote of n=2.
It's not great, but it works I guess. I do wish we were on SaltStack or Ansible instead.