5 ms·

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

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.

TinyRick 6y ago
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 http://www.chef.io/customers
- geerlingguy 6y ago
  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.
  - carlosf 6y ago
    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.
    - user5994461 6y ago
      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.
      - miah_ 6y ago
        Consider that Chef Infra has 2 core developers and its not surprising why.
    - notyourday 6y ago
      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.
    - devonkim 6y ago
      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.
  - nunez 6y ago
    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.)
  - chucky_z 6y ago
    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.
hardwaresofton 6y ago
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 https://www.ansible.com/use-cases/provisioning [1]: https://www.terraform.io/docs/provisioners/ https://www.terraform.io/docs/provisioners/
- zimbatm 6y ago
  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 https://github.com/numtide/terraform-provider-linuxbox
  - deleted 6y ago
    [deleted]
  - hardwaresofton 6y ago
    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.
- 6y ago
swalberg 6y ago
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.
- rmoriz 6y ago
  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.
  - twunde 6y ago
    `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)
mianos 6y ago
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.

TinyRick 6y ago

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 http://www.chef.io/customers

geerlingguy 6y ago
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.
- carlosf 6y ago
  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.
  - user5994461 6y ago
    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.
    - miah_ 6y ago
      Consider that Chef Infra has 2 core developers and its not surprising why.
  - notyourday 6y ago
    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.
  - devonkim 6y ago
    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.
- nunez 6y ago
  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.)
- chucky_z 6y ago
  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.

hardwaresofton 6y ago

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 https://www.ansible.com/use-cases/provisioning [1]: https://www.terraform.io/docs/provisioners/ https://www.terraform.io/docs/provisioners/

zimbatm 6y ago
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 https://github.com/numtide/terraform-provider-linuxbox
- deleted 6y ago
  [deleted]
- hardwaresofton 6y ago
  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.
6y ago

swalberg 6y ago

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.

rmoriz 6y ago
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.
- twunde 6y ago
  `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)

mianos 6y ago

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.