Hacker News Reader

Comment by user5994461 | Hacker News Reader

My 2 cents on Chef is that's it's long dead. The handful of people I know who used chef professionally all gave strong negative feedback about it and moved away to ansible.

While I can't comment on the exact problems because I didn't use it personally, there was a recurring mentions of losing states, seemingly destroying systems and configurations instead of setting things up. People were adamant that moving away from Chef was the best thing they've done lol, which I don't know about but I take at face value after the third person saying the same thing.

View on HN

While I'm not a proper sysadmin, Ansible is what I gravitated towards (and use for my own projects) and always seemed like the best choice out of Chef, Puppet, and Saltstack.

Ansible is/was straight forward to use and understand, very F/OSS, relatively easy to orchestrate (even without tower), and had a nice ecosystem. Ansible always won for me because it was simple, and had just enough (though I always felt that the roles/tasks analogy was kind of awkward) and was easy to hack. These things were mostly true about Chef, but outside of being "ansible, but ruby", I don't remember distinctly what made Chef worth doing other than if it was there before you got there.

Someone please correct me if I'm wrong but IIRC Salt was one of the first to start venturing into the infrastructure provisioning realm and ansible went there too relatively easily though it's somewhat obscure[0]. Ansible and Chef (and presumably puppet) were quick to follow/build similar tooling but we all know who won that race -- Terraform.

Funnily enough, Terraform is now making it's way back around to eat the post-deploy logic as well with it's provisioners[1]. Can't wait to see HCL grow into an even more grotesque monster.

[0]: https://www.ansible.com/use-cases/provisioning

[1]: https://www.terraform.io/docs/provisioners/

Another approach that we have been exploring with Terraform is to treat the machine configuration as resources[1]. It works pretty well when most of the system is vanilla with a few additions to it (like installing Docker).

[1]: https://github.com/numtide/terraform-provider-linuxbox

Thanks for making this available as open source -- I was about to note that this is exactly what providers are for, then read the use-cases and the support/API surface you've crafted, this looks super useful.

I was anti-HCL/Terraform for a long time due to issues with state files, but lately I honestly prefer it over Ansible whenever possible.. although I'm still not happy with the way cloud-init works on various cloud providers.

I'd like to recommend that you try pulumi. Terraform is definitely a fantastic tool, and it really does have just about everything you want (and is extremely google-able with easy to find experts), but I think the bring-your-own-language paradigm is better for this particular use case if a few things are true:

- Your team is comfortable with at least one of the languages Pulumi has native support for, ideally your codebase/infrastructure repo is already written in it.

- Someone on your team isn't going to hang everyone else and themselves with the wide open nature of a fully featured programming language at their fingertips

- You've got some innovation tokens to spend

I think HCL is going to get more and more like a fully featured language as time goes on -- if they ever lean in to it (and introduce support for alternative "language runtimes" or something) then I would go terraform and never look back.

It's hard to recommend pulumi over terraform because of momentum, ecosystem, etc, but it does seem like a better base to start off of (and it's what I use for my own stuff).

And also because terraform is also working on enabling other languages on top of it: https://www.hashicorp.com/blog/cdk-for-terraform-enabling-py...

Thanks so much for the pointer, didn't know this existed -- it's exactly what I was hoping they might do.

> Today, we are pleased to announce the community preview of the Cloud Development Kit for HashiCorp Terraform which allows users to define infrastructure using TypeScript and Python while leveraging the hundreds of providers and thousands of module definitions provided by Terraform and the Terraform ecosystem.

> CDK for Terraform is in alpha and is in the early stages of development. This project is another way to interface with Terraform using languages like TypeScript and Python. We are working to support additional languages such as JavaScript, Java, and C#. In addition to language support, we plan on expanding the scope of CDK for Terraform project to support other first-class commands to provide a user experience similar to the AWS CDK.

This has to be a shot across the bow at pulumi, glad Pulumi innovated and took this direction (maybe CDK was on the roadmap at Hashicorp, not sure) and seemingly spurred TF taking the turn as well.

HCL, Jinja, Go Templates, etc are much easier for people to read and understand than standard programming languages. If you're going to use a standard programming language to write your IaaS then you might as well just use the native SDKs rather than an overlay.

I brought Chef into the online side of the NFL several years ago. We still use it, though less and less as we get more things into containers. I've got my gripes with it, but I'd never second guess my decision to use Chef, or trade it for anything else.

Those problems sound like people aren't taking the same care in their cookbooks that they are in their regular software. If you write bad cookbooks and don't at least give a cursory review of the community cookbooks you use, you'll end up with a mess. If you treat it like the customer facing software it is, I find it a pleasure to work with.

Our cookbooks have CI pipelines that run some basic tests and we have automation around rolling out changes. We rely on a lot of conventions to avoid storing state, but we still have nodes auto provisioning their own storage and load balancers where necessary. It's let us stand up a ton of infrastructure and make changes safely and quickly. That's not to say we couldn't have made Puppet/Ansible/etc work, because IMHO it's more about your development practices than anything else.

edit: we only use Chef Infra and some Inspec. Not talking about Habitat.

I'm using Chef since 2010 for myself and customers. I never understood the hate but I saw so many developers not getting it and/or overengineering it to a state which was beyond their capability to debug.

For example the different levels of attribute types. I saw "senior" developers writing nasty Ruby code (actually `system("rm -rf directory")` to delete directories (outside the chef DSL) because they didn't understand the appropriate chef resource.

The market decided to take away the power of a real programming language DSL as an interface. People are now forced to deal with terraform (HCL), YAML or JSON. It's a lobotomy.

`The market decided to take away the power of a real programming language DSL as an interface. People are now forced to deal with terraform (HCL), YAML or JSON. It's a lobotomy` I feel this so much. Granted HCL is taking steps to become closer to a real language but its frustrating that some of the features that I used to take for granted are missing (why do we have ternary if statements in HCL but not real if-else blocks. I used to enforce a rule that you should not have nested ternaries, but now that's the only way to do if else if statements)

It's going back, at least on the HCL front. Have a look at Pulumi and prepare to throw TF in the trash.

I can confirm that the NFL Chef cookbooks were great. I worked at the NFL and previously introduced Chef at a startup beforehand. The biggest issue I had at the startup were application developers cutting corners when creating ANY infrastructure code, not just Chef recipes. The devil IS the details when it comes to infra code, and the lack of detail, not the tool itself can really bite you.

I disagree that it's "long dead". Keep in mind that Chef (the company) has several different products too...Chef Infra (traditional configuration management) has fallen out of favor and Ansible seems to be the popular choice these days, but there are still a lot of big Chef Infra shops (e.g. Facebook [0]) that have invested heavily into configuring their environments using Chef Infra, which would require a good bit of investment to switch tools.

Plus, they have been diversifying their products in recent years with things like Habitat (application packaging/deployment) and security/compliance tools (InSpec).

[0] http://www.chef.io/customers

The fact that I've never heard of Habitat or InSpec means either they're extremely niche and not as popular as I think Chef would've hoped, or I'm completely out of touch with both app packaging and sec tooling.

I'm hoping it's the former, but I wouldn't be too surprised if the latter since the 'enterprise' ecosystem of cloud tooling has grown exponentially in the past decade.

You're not out of touch, Terraform + Containers + People realizing that building immutable things is much better than managing state pretty much killed Chef and Puppet.

People still have to manage quite a bit of setup for kubernetes/containers though... and that configuration usually happens with ansible, not chef. I think it's fair to say that Chef has failed to hold their market.

Consider that Chef Infra has 2 core developers and its not surprising why.

People love talking about their state being immutable when in 99.9% of the cases it is not.

Here's a simple test: if your runtime container infrastructure is immutable, you should be able to run your container with a file system being read-only. If you cannot do that, then you do not have an immutable infrastructure and hence you will need need something to manage the state. Ignoring it is akin to kicking housekeeping tasks to some point in future and hoping that before you get buried under the multi-year backlog of tiny corner cases before your entire product is replaced with something else.

After having spent the past decade across about 12+ companies in various capacities furiously trying to make software immutable and to isolate state to dedicated services like DBs, message brokers, and networked caches, I’m not sure if it’ll go away without many companies rewriting software from the ground up effectively to support cloud native-ish assumptions like 12F but much more like avoiding leaving transactional state on-disk that can’t be recovered. There’s a TON of software out there that is written like it’s the 90s still. The market for managing legacy stateful software is matured to its finality and nobody wants to try to attempt to revolutionize it anymore is what I’m seeing, not that nobody is doing it anymore. Essentially, if one is writing new software that isn’t containerized in 2020 you’re writing the systems equivalent of COBOL.

But anyone could see many years ago that it’s easier to flatten and reinstall stuff than trying to painstakingly manage various moving pieces. We were limited by our technology unless one was using stuff like zones in BSD or Solaris.

The surprise for me has been how rapidly huge behemoth organizations like the DoD has shifted to technologies like K8S when they took so many years just to get onto VMware and some configuration management.

Holy shit; if /u/geerlingguy hasn’t heard of Hab or InSpec, then Chef really could’ve done a better job marketing them. (This user is very well known in the config management space.)

InSpec is really a good tool you should know. I believe you can write molecule tests with it so it’s something you may have already used at this point and not realized it.

Having used both. If I look around I see Chef used less and less and Ansible more and more but that does not mean there is a valid path from Chef to Ansible when you way more than a trivial number of hosts. I'd say go from Chef to Saltstack. If you only have a few hosts, sure Ansible.

Reply on news.ycombinator.com