Also the Chef server is more complex and written in more languages than the stack of an entire early-stage startup https://docs.chef.io/chef_server.html
And the server uses its own versioning, because what I really need is something competing with my DVCS
To make this a fair comparison, you should be comparing chef-solo (or chef-zero) deployments to Ansible since the closet thing Ansible has to a dynamic source of truth is dynamic inventories. But we'll table the discussion of whether or not I should be required to build my own CMDB from scratch or not for now...
The Chef Server stack is somewhat complicated, though with an omnibus install you will rarely have to interact with it at that level. These days, it scales well up to thousands of client nodes with no meaningful effort.
I'm not sure what you mean by the server using its own versioning. Cookbooks are versioned, as they are deployable artifacts. Environments then define which versions of all the cookbooks exist, so you have an easy promotion strategy. The challenge with Chef Server and DVCS is that you have to centralize the uploading of Chef artifacts (roles, environments, data bags, cookbooks) to Chef Server if you have a team with more than 1 person. That challenge is not unique to Chef, however. Hopefully, a team of Ansible users are not running Ansible playbooks directly from their workstations. If you try to upload a version of a cookbook that is older than the current version, it yells at you, so it makes certain bad behaviors more difficult.
There is plenty I don't like about Chef. And Puppet. And Ansible...I've worked with all of them, but I still haven't seen a valid argument to support the phrase "over-engineered" when used on Chef. Of all the configuration management products out there, Chef is still the most flexible and the most powerful.
>The Chef Server stack is somewhat complicated, though with an omnibus install you will rarely have to interact with it at that level.
Omnibus is the worst thing to happen to packaging. It bundles its own copy of everything.
Is anyone that's not an Opscode employee capable of building Chef Server from source? I tried and failed. Software that can't reasonably be built from source is proprietary in practice. I want to run Chef Server on Debian but I can't because its seemingly impossible to build, so I can only use a platform that Opscode provides a pre-built binary for. It's a terrible situation to be in.
In what way is attribute precedence over-engineered? You can ignore most of it for most cases and just use default for everything, but when you need it, it's there for you. I don't see how it's more or less simple than what Ansible has defined: http://docs.ansible.com/ansible/playbooks_variables.html#var.... I count 16 precedence rules in Ansible 2.0.
Every time a new configuration management utility comes out, everyone loves it because of it's simplicity or some arbitrary measure of "lightweight," but once Systems Engineers need to solve real automation problems in the real world, they start adopting features to work around the illusion of being "lightweight."
I like Ansible for automating my home network where I have simple problems and no need for environment separation. For professional work, I stick with Chef or Puppet.
I don't think that's a very good example. Attribute precedence is easy to understand, and it's very necessary. After working with it for a bit it becomes very intuitive.
And all of the config management tools have a comparable concept. Ansible 2.0 has 16 levels of variable precedence, Puppet has hiera which gives you arbitrary levels of precedence, and Chef has attributes, of which there are 11-15, depending on how you count.