Cooking up savings, one local dev environment at a time
July 27, 2019

Cooking up savings, one local dev environment at a time

Christopher Maggiulli | TrustRadius Reviewer
Score 8 out of 10
Vetted Review
Verified User

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.
I've mostly explained the differences between Ansible and Chef in my previous answers. I generally prefer Chef over Ansible because the platforms we use have very convenient cookbooks.
Liferay Digital Experience Platform (DXP), SAP Commerce Cloud (formerly SAP Hybris), Oracle Service Bus
It loads quick enough for basically all our systems. Because we have this for local dev environments, speed isn't really a big issue here. Yes, depending on the system, sometimes it does take a relatively long time, but it's not an issue for me. One thing that is annoying is that if I want to make a small change to a cookbook and re-run the Chef client, I can't just make the change in the cache and run it. I have to do the whole process of updating the server.
I have easily found cookbooks for our Liferay platform and other enterprise Java platforms. But, in all fairness, you can find Ansible playbooks for them, too. But the 10/10 comes from the fact that there is a great Chef cookbook for various pieces of Oracle Fusion Middleware (FMW). FMW is notoriously the hardest to configure enterprise platform out there.
We run a large Liferay platform with a heavy load and high availability. We may have 6 developers working on the platform at a given time, and it takes them a week just to learn to set the environment up. With Chef, we can provision them a "local" environment with the push of a button.


In some instances we find Chef to be overkill. We have a large application landscape and some of our applications don't follow the traditional DTAP model (especially in systems that have serverless cloud components). We find the time it takes to write a cookbook for these systems may not provide a return on investment, especially if it isn't a critical system

Comments

More Reviews of Progress Chef

  1. Home
  2. Configuration Management Tools
  3. Progress Chef Reviews
  4. User Review of Progress Chef