Chef - Cooking up Trouble
Overall Satisfaction with Chef
Chef is great for getting people not currently experienced with platform tools up and running as quickly as possible. Instead of spending months trying to figure out the platform/build tools/distro technicalities, they can get right to work on projects that can be targeted at any application with any servers that are running any OS/programs.
Pros
- Uses DSL for configuration instead of the conventional XML
- Rackspace has extensive support for it and it integrates well into almost any cloud platform (AWS, Azure, etc.)
- The concept of recipes is great and allows for multiple machines with different operating systems and configurations to be updated in a similar way even if they share almost nothing in common
Cons
- Configuration management hits a critical mass where it can take almost an entire team to support it. Determine that you need to have all your machines on the same page first before you commit to using Chef in your infrastructure
- Requiring installation on machines can be a pain compared to the agentless nature of competitors such as Ansible
- Ruby as a configuration language can take a while for an unfamiliar engineer to learn and often negates the benefits of configuration management in the first place with the amount of time it takes up
- Led to concurrency in machine updates for our more extensive applications.
- Allowed team members to become effective in minimal time.
- Required extensive management of scripts and deployment when we want to update machines, making small changes a considerable undertaking.
Chef is something we have been using for a while, so it is the natural choice when training new engineers to maintain our systems. If I was to choose a configuration management tool now, I would pick Ansible mainly because of its agentless nature and YAML cookbook language (compared to Chef's Ruby).
Comments
Please log in to join the conversation