Cooking up savings, one local dev environment at a time
Overall Satisfaction with Chef
Chef is used in a variety of different fashions through my organization. At the highest level, it is used by our DevOps team to automate deployment of infrastructure related to non-production (Dev, Test, UAT) development boxes.
Pros
- The best things about Chef are the Cookbooks, making implementation fast
- Very wide adoption in the open source community
- I love the Ruby DSL
- Love that it's implemented in Erlang which makes it especially quick
Cons
- It's developer-oriented, which I like, but some of our sysadmins use Chef too, and they aren't great with it. It would be nice if there was a layer of abstracting for simple jobs to reach a wider user audience
- For somewhat of same reason, it's harder to manage than Ansible
- The absolute biggest issue is source of truth. You can't use git as your source of truth in Chef like you can in Ansible
- It's also hard to manage because your have to keep your Chef server and repo in sync
- Huge return when onboarding new developers. We run a lot of platforms at my company (Liferay, Hybris, Oracle SOA, RabbitMQ, ColdFusion 8, ColdFusion 11, Oracle Service Cloud, and many more). To get these local environments set up it would take a new hire months to learn all that before we used Chef.
- We lose some ROI when the Chef server and source control become out of sync.
- Traditionally, our sysadmins provisioned and configuring new local dev instances. But by handing off non-production configuration automation to DevOps, we get things done faster.
- Ansible, Puppet Enterprise (formerly Puppet Data Center Automation) and Puppet Pipelines (formerly Distelli)
Comments
Please log in to join the conversation