CINC Is Not Chef

2025-04-0417:225454cinc.sh

CINC is not Chef

A Free-as-in-Beer distribution of the open source software of Chef Software Inc. See goals for details, or follow our blog for updates on the project.

The Cinc team is proud to present:

Cinc Projects

Coming Soon

Come chat with us! community slack channel #community-distros


Read the original article

Comments

  • By don-code 2025-04-0419:382 reply

    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.

    • By nyrikki 2025-04-0419:59

      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...

    • By nunez 2025-04-0419:46

      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.

  • By kureikain 2025-04-0418:341 reply

    If you're still fighting with Chef slowness, hard to debug, complicated setup, you may want to consider Pyinfra.

    It is very well thoughout and simple to design and run.

    • By geerlingguy 2025-04-0419:43

      It targets a different audience overall.

      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.

  • By echohack5 2025-04-0420:30

    Man I miss Chef. It was wildly good for its time with a vibrant community. Habitat was cool but tried to carve into some niches that were too ambitious. And InSpec was an incredible tool but failed to build the critical community to drive it forward. I haven't experienced anything like the Chef Community since. (AI has some of these vibes in small pockets but it's very disjointed)

    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

HackerNews