Live data from Hacker News

CINC Is Not Chef

cinc.sh

41–50 of 57 posts

Re: CINC Is Not Chef

#41

2013 called and wants its favorite infrastructure as code (IaC) tool back.

Tools don't stop being useful just because they aren't trendy. I still use Chef, and I love it. I much prefer it to Ansible or Puppet.

All three of those tools immediately felt, to me, like the wrong approach the moment I first experienced Docker. The notion that production infrastructure should be mutable and we use automation to make changes to it just introduces so much more state than is necessary. Immutable infrastructure eliminates so many sources issues.

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.

Re: CINC Is Not Chef

#42

I haven't encountered any Chef code in almost ten years. For the stragglers not yet primarily on Kubernetes and Terraform, I see Ansible and some extra Terraform. Maybe I see some Salt here and 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…

I think you would be quite shocked to discover how many millions (10s of millions?) of nodes at hyperscalers and adjuncts are configured with 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.

Re: CINC Is Not Chef

#43
post #25

I legitimately have no idea what infrastructure provisioning tool to use anymore. I normally defaulted to Saltstack Masterless and Chef via Packer. What "simple" tool is left anymore for me to create my immutable AMIs that aren't bound by some license?

They're all good and bad in different ways. You just need to pick one. Ansible is GPL3, opentofu is Mozilla Public License.

Re: CINC Is Not Chef

#44
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

Re: CINC Is Not Chef

#45
post #37

What is Chef? This website fails to answer that.

To quote the first line of the website: > 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.

Re: CINC Is Not Chef

#46
post #41

Earlier quoted context omitted.

Tools don't stop being useful just because they aren't trendy. I still use Chef, and I love it. I much prefer it to Ansible or Puppet.

All three of those tools immediately felt, to me, like the wrong approach the moment I first experienced Docker. The notion that production infrastructure should be mutable and we use automation to make changes to it just introduces so much more state than is necessary. Immutable infrastructure eliminates so many sources issues. And I think that's where the comment you're responding to is coming from. Once you've exp…

Docker, k8s, Terraform etc are nice. I make extensive use of them too. But in my opinion they can't be used for everything, because mutable infrastructure is a reality of the world that must be accounted for at some point. For example, at my employer we have on-prem k3s clusters running on bare metal servers. Chef is a perfect tool to manage those, because they are by their nature not something we can treat as stateless, immutable configurations.

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.

Re: CINC Is Not Chef

#47

I haven't encountered any Chef code in almost ten years. For the stragglers not yet primarily on Kubernetes and Terraform, I see Ansible and some extra Terraform. Maybe I see some Salt here and 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…

I think you would be quite shocked to discover how many millions (10s of millions?) of nodes at hyperscalers and adjuncts are configured with 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.

Terraform and Chef definitely go well together. Like peanut butter and chocolate. Terraform is great at provisioning cloud resources but not so great at configuring the details once they're up, Chef is great at configuring servers that exist but can't do squat to provision them in the first place. At my job we use both of them quite a bit to manage our stateful EC2 instances, because of the way they complement each other.

Re: CINC Is Not Chef

#48

Earlier quoted context omitted.

I liked writing chef, but the client/server model and its knock on effects (IIRC, needing to upload changes with knife?) was annoying. Ansible is more painful to write but a delight to run.

The client/server model is why I like Chef more than Ansible, tbh. Having my machines run a service which pulls configuration on a schedule is, to me, much saner and easier to manage than having to push configuration from a central source over ssh. But that is obviously just my preference, and if someone doesn't like the client/server model then I can totally understand if they don't like Chef as a result.

To me a deployment of new code or config is a workflow. The ordering and timing of its progress of the fleet is very important. You want to be able to plan it, watch it, and pause or reverse it from that perspective.

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.

Re: CINC Is Not Chef

#49
post #25

I legitimately have no idea what infrastructure provisioning tool to use anymore. I normally defaulted to Saltstack Masterless and Chef via Packer. What "simple" tool is left anymore for me to create my immutable AMIs that aren't bound by some license?

For creating AMIs? Probably Ansible or something similar. Chef is great for ongoing management of servers, but not so good for a one-shot config run like you would do if you're creating AMIs.
Post reply on HN