Automation and integration
One of the best parts about Chef is that your infrastructure and software model is consistent with what is deployed. What this means for you is that when chef-client runs on an endhost, that host's state is updated to match your modeled environment. For example, consider a scenario where you have 10 EC2 database hosts, and all of them have a special role, database_server, applied to them. This role's attributes indicate that PostgreSQL 9.1 is to be installed and its data should be stored in /opt/postgresql/data. By executing chef-client on all ten nodes, they will have PostgreSQL 9.1 installed and storing data in /opt/postgresql/data. Now consider that all of our nodes need to have a new EBS storage device attached to each of them, and PostgreSQL needs to be pointed to our new EBS device. Updating our model to include a recipe that mounts the EBS device gracefully shuts down PostgreSQL, moves the database data, reconfigures PostgreSQL, and starts it up again. We can automate and roll out this configuration to our fleet of ten database hosts. You can easily imagine ten hosts growing to hundreds or even thousands. This is what the power of automation is all about.
Automated updates and deployments
If you have confidence in your model and your cookbooks, then you can take this automation one step further. By automating the execution of chef-client on a periodic schedule, you can fully automate updates without needing to SSH into the hosts to run chef-client. However, this level of automation requires a high level of confidence in the correctness of your cookbooks. Achieving this requires continuous and in-depth testing of not only the code in the cookbooks developed but also of the dependencies that are needed to make your cookbooks work. To that end, comprehensive integration tests can help to build the confidence needed to move into a fully automated world.