These systems are broadly the same. If you're writing your configuration from scratch, they're all fairly pleasant, and it's mostly a matter of preference. They share most of the same concepts (although the terminology differs) and features. In my experience, their differences are primarily in feel and community.
For feel: Chef gives you Ruby pretending to be declarative. Puppet and Ansible give you something more declarative at the expense of some expressivity. Puppet has its own syntax, and Ansible shoe-horns some procedural aspects into YAML syntax. I prefer Chef here. (Chef also provides a web UI that lets you edit things, but I strongly advise against using it except for managing nodes. Everything else should be code/JSON.)
For community: With configuration management, one of the things you'll want is good community involvement. You don't want to write every cookbook/playbook/module from scratch. From what I've seen, Chef and Puppet have a large head start in this department.
That said, you should be prepared to customize the community offerings. People generally implement precisely what they need, in precisely the way they need it, and your needs will not always align. Fork all of the community offerings so you can modify them while still pulling from upstream. Managing this is decidedly difficult, but there's no better choice. It's one of the areas where git submodules would be really great, if only they were nicer to use. If you're going to use Chef, consider also using Berkshelf for managing your cookbooks.
If you do not have configuration management in place, pick one of the major ones, learn the hell out of it, and get to automating your operations. Having your infrastructure as code that you can run whenever you want, that you can review to see exactly how something is configured, is life changing. Once you get to doing it, you will never want to go back to the bad old days.
Chef and Puppet are quite different, in my opinion.
Based on my exposure, Chef ultimately boils down to being a complex remote execution framework. Puppet makes detect-and-correct more central to its model.
Dell and Amazon leveraged chef to help build Crowbar and Opsworks respectively. Crowbar ... leveraging ... get it?
In any case, noting Opsworks is based on Chef is not an "appeal to authority".[1] That knowing Chef means you have a head start on AWS's official devops tooling, seems a relevant data point for a comparison. (The officially supported devops tooling leveraging a particular CM system is different from simply being able to be managed by a CM system.)
As for Rackspace, here's the CM category of their dev blog:
Quoting a different Rackspace article from Feb 2013:
The Rackspace Private Cloud Certification team sought out and tested a number of bare metal provisioning tools. While there are a number of excellent tools on the market, none seemed to fit quite well. On one hand, some tools were all-encompassing in scope and would try to provide an end-to-end solution. On the other hand, tools were too narrow in scope and provided a solution for a specific operating system or did not provide an appropriate amount of flexibility.
Eventually, we picked a deployment model consisting of a combination of tools that would provide the right balance of features and flexibility. We chose the Razor provisioning engine, combined with the OpsCode Chef configuration management tool.
It's on the list, too, but I (possibly incorrectly) see Chef and Ansible having a more similar philosophy and workflow to each other than to Puppet so I am hoping to eliminate one of them.
