Simplicity wins out.
Why Ansible Suits Us Better Than Chef
I'd been happily using Chef for about six years and had invested a lot of time into researching, learning and setting up our agency server provisioning suite. It was a bit tricky to use sometimes and certain aspects of it seemed more complicated than they needed to be. To me at least.
When I first came across Ansible I was sceptical. Did I really need to retool at this stage? What were the benefits? Is this new-fangled?
Well, all of those concerns went in the wastebin and I'm happy to report that I've been using Ansible for some time now and probably wouldn't switch back.
Its not that there is anything deficient about Chef, in fact I still think its great, but for ease of use and peace of mind, Ansible is now my go-to server provisioning framework - I even use it to install Minecraft on my son's Raspberry Pi!
Here are some of the reasons why I'd encourage any Devop to try Ansible:
1) Ansible is agentless
This means that server nodes don't need to have any software installed on them in order to be managed, they can be bare server nodes. Chef on the other hand uses a server-based agent that runs on each server node, which must have access to the server provisioning server. This means that, unlike Ansible, Chef server nodes cannot be installed on "fresh" server nodes - they must be pre-configured with the Chef server software.
Ansible can be run remotely on a server provisioning server, or locally on the server nodes themselves. This makes it very versatile and easy to use.
2) Ansible configuration uses YAML
This makes them easier than Chef to read and edit for server provisioning purposes.
3) Ansible playbooks run in parallel
This is a great time-saver when provisioning multiple server nodes. Chef recipes can only be run sequentially.
4) Ansible is platform agnostic
It can be used to provision server nodes on Linux, Mac or Windows server operating systems. Chef is only really suitable for provisioning Linux server nodes.
5) Ansible has a large and active user base
This means that there is a lot of help and support available online if you need it. Chef has a smaller user base, which can make finding help a bit more difficult.
6) Ansible is open source and free to use
Chef is not open source, which can make it complicated to use for server provisioning purposes.
7) Ansible is easy to set up
All you need to get started is an Ansible server provisioning server and Ansible installed on your workstation. Chef requires a lot more set up, including the installation of a server provisioning server and a server node agent on each server node.
8) Ansible is free from learning curves
It is easy to learn and use, even for server provisioning beginners. Chef can be a lot more difficult to learn and use, especially for server provisioning beginners.
9) Ansible is well-supported by the community
There is a lot of help available online if you need it. Chef is not as well supported by the community, which can make server provisioning issues harder to resolve.
10) Ansible has a growing number of modules
This means that it can be used to manage a wide range of server nodes. Chef has a smaller number of modules, which can make server provisioning a bit more time consuming, as you may you have to create from scratch.
11) Ansible is easy to automate
Ansible can be integrated easily with other server provisioning server software. Chef requires more server provisioning server software integration to automate server provisioning tasks.
Ansible fanboy, 100% official.
Okay, so there was a bonus one in the for the creative tech types. Please, please do give Ansible a try when you have an hour to spare - it can be tested with Vagrant for speed and I promise you won't be dissappointed.