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&#x27;ll table the discussion of whether or not I should be required to build my own CMDB from scratch or not for now...<p>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.<p>I&#x27;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.<p>There is plenty I don&#x27;t like about Chef. And Puppet. And Ansible...I&#x27;ve worked with all of them, but I still haven&#x27;t seen a valid argument to support the phrase &quot;over-engineered&quot; when used on Chef. Of all the configuration management products out there, Chef is still the most flexible and the most powerful.