Chef Reviews

39 Ratings
<a href='https://www.trustradius.com/static/about-trustradius-scoring' target='_blank' rel='nofollow noopener noreferrer'>trScore algorithm: Learn more.</a>
Score 8.3 out of 101

Do you work for this company? Manage this listing

Overall Rating

Reviewer's Company Size

Last Updated

By Topic

Industry

Department

Experience

Job Type

Role

Reviews (1-13 of 13)

Brittany Woods profile photo
Score 9 out of 10
Vetted Review
Verified User
Review Source
We are using Chef across many teams, both operations and development. We use Chef to manage configuration for our on-premise systems.
  • Configuration Management: Chef is an easy and efficient way to manage configurations, both during and post-deployment of your systems.
  • Visibility: Chef Automate provides great insight into your infrastructure and gathers huge amounts of data to give you insight into system configuration.
  • Integrations: Chef is working hard to provide meaningful integrations to Chef Automate that will allow it to rise to its extremely powerful potential.
  • Customer Success
  • Community: The Chef community is second to none! Chef has really done great work ensuring they have fostered a friendly, welcoming, and inclusive community for their users.
  • Ease of use: Once you get your hands around it, Chef is very easy to use. Many resources within Chef follow similar patterns so it’s relatively easy to develop basic cookbooks right from the beginning.
  • Ease of migration: Because many initial users of Chef are not necessarily comfortable “coding”, Chef gives the ability to plug scripts into resources making migrating from bash and power shell scripting extremely easy. As you get comfortable, plugging and playing Chef resources in place of once used scripts is mostly seamless.
  • Dashboards: Automate is a very powerful tool. They should allow the creation of custom dashboards by users themselves, as there are too many use cases for the data provided by Chef for a single company to try to stay on top of that.
  • Extending User Roles: Dashboards should tie into IAM roles within the platform. Let me show users what they care about without them having to know what to filter.
  • Limitations in Provided Integrations and Within Automate: Chef has provided a great integration with AWS, allowing one to scan entire accounts or ec2 instances within an account. That said, using this as a scheduled job only scans ec2 instances that exist at the time the job is set up. Continuous scanning of assets within the account through the integration appears to not be occurring, which is a real bummer. Additionally, I think it's important to get user input into how they're actually expecting to use the tool to fully understand what users need in terms of automation, especially around the compliance portion of the tool. Finally, I think it's important to ensure that key features (like scheduled scan jobs) work in the desired way or document workarounds prominently.
  • Communication with existing customers: As stated above, if something doesn't work exactly as it should, there's no shame in effectively communicating known workarounds to customers and users. We understand improvement takes pain sometimes, but if you know a way around it, throw that information out there and save others some valuable time.
Chef is extremely valuable when there is a need to manage configurations. Chef is also becoming extremely useful for one-off changes with their chef-run tooling in Chef Workstation. Habitat is becoming increasingly beneficial for the cloud/containerized immutable world. Inspec is something companies shouldn't live without. Chef appears to be working hard to ensure that no matter the use case they have the ability to help make lives easier and more automated.
Read Brittany Woods's full review
Christopher Maggiulli profile photo
Score 8 out of 10
Vetted Review
Verified User
Review Source
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.
  • 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
  • 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
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
Read Christopher Maggiulli's full review
No photo available
Score 10 out of 10
Vetted Review
Verified User
Review Source
We use Chef to create our AWS environments with infrastructure as code, using Chef cookbook with recipes to create and configure services. Along with puppet, Chef made it easier to achieve IAAS for our cloud-based applications and to manage 6 different environments.
  • Easy to install and configure.
  • Ease of use.
  • You can spin up the environment in minutes.
  • Very simple syntax.
  • Easily replicated to build multiple environments.
  • Infrastructure as code goals.
  • Devops work is easier than ever.
  • It needs some initial learning curve.
  • Some Ruby knowledge is required.
  • For Infrastructure as code, you may have to disable all the services to configure any single service.
For our cloud-based applications with multiple environments and microservices, Chef made life easier with infrastructure as code. Along with using puppet, we can bring up or configure the environments in minutes. Any charges to services can be easily managed using recipes and cookbooks. It's easy to learn, with much less/no learning curve if you know Linux/ruby. It's flexible to manage multiple cookbooks for different environments, and works well with the puppet.
Read this authenticated review
Dylan Cauwels profile photo
Score 7 out of 10
Vetted Review
Verified User
Review Source
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.
  • 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
  • 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
Chef is great for managing large amounts of servers and ensuring that your applications run the same on all of them. While it may take a bit to learn Chef, the time saved is incredible at the end of it. However, if you are just getting into configuration management tools I would recommend looking into Ansible as it has a few key tradeoffs with Chef that can be substantial resource savers.
Read Dylan Cauwels's full review
No photo available
Score 9 out of 10
Vetted Review
Verified User
Review Source
Our organization uses Chef to deploy new code in an automated fashion. We also use it to update existing configurations and push those changes in an automated fashion to large groups of servers. Having the ability to deploy simple or full system changes out to a large group of servers with little human interaction has been a game changer for our company allowing us to deploy at scale and grow our infrastructure as our company grows.
  • Chef is great at deploying code to both small and large groups of servers.
  • We use chef to standup new servers as well as deploy updated code to existing servers and it does this very well.
  • Being able to make a change and have it push manually or automatically to any subset of servers has changed the landscape of how our IT teams operate.
  • Chef can be very complex, but therein also shows the unlimited possibilities of what you can do with it.
  • I would like some better reporting on the status of a deployment from Chef, but I feel this can be obtained with other products that can be incorporated to work in conjunction with Chef.
Our organization uses Chef to deploy new code in an automated fashion and it excels in this aspect. It is also well suited to updating existing configurations and push those changes in an automated fashion to large groups of servers. Having the ability to deploy simple or full system changes out to a large group of servers with little human interaction has cut down on time lost spinning up individual servers and allowed our teams to focus on other, operational problems and made us more efficient in dealing with problems with impact customers as opposed to building servers. Chef has enabled us to deploy at scale and helped grow our infrastructure as our company grows.
Read this authenticated review
No photo available
November 28, 2018

Get Cookin with Chef

Score 9 out of 10
Vetted Review
Verified User
Review Source
Chef is a tool that is being used as part of a DevOps enablement movement that we are implementing throughout our business unit, and hopefully our organization in the future. It will help automate the manual task of creating and configuring new servers, testing existing servers for compliance regulations, as well as providing on-going maintenance for our infrastructure.
  • Chef is very easy to learn. Written in ruby, Chef code is high enough level for non-ruby coders to get a general idea of what the script is doing.
  • Chef can be a one stop shop for writing code, testing infrastructure, and deployment of applications.
  • The Chef support team is very helpful in their auto manager support as well as active support in their Slack channels from development engineers & architects.
  • Chef could do a better job with integration with other DevOps tools. Our company relies on Jenkins and Ansible, which took some development and convincing for plug-ins to be created/available.
  • It would be nice if kitchen didn't only have a vagrant/virtual-box prerequisite. Our company one day stop allowing virtual-box to run without special privileges, and that caused a lot of issues for people trying to do kitchen tests.
  • Chef could use more practice materials for the advanced certification badges. There was not a lot of guidance in what to study or examples of certain topics.
Chef is really great when teams are attempting to migrate over from legacy systems. In our case, it was a switch over from AIX to Linux. Thus, it was a great opportunity to use Chef to build out deployment cookbooks that could then be used win order to set up the new servers in preparation for the upgrade.
Read this authenticated review
No photo available
Score 8 out of 10
Vetted Review
Verified User
Review Source
We use multiple Chef servers. We had 2 Chef servers hosted in our Business Unit, one for production and another for pre-production. We developed on that and maintained them too. Apart from these 2 we have organizational wide Chef servers which can be used by any BU and a central tools team maintains those servers. We are using Chef not only for IaC but also for deployment purposes.
  • Chef helps maintain all the servers of one logical group to be in the same state. This helps in maintaining a standard across all the servers.
  • Concepts in Chef like roles, environments and tags helps a lot in logical grouping and executing corresponding cookbooks on them to maintain the stability.
  • We use Chef not only for infrastructure as code but also for reliable deployments.
  • One main concern with Chef is the maintainability of Chef master.
  • The Chef-client should be installed on every node we want to do any automation.
  • It is mostly Ruby and there's a learning curve. Need to understand the fundamentals of Chef very throughly to play around with attributes, templates etc etc.
  • The Chef-client agent needs to be run on the nodes frequently to update the details of it state to master. And also to index the nodes based on tags.
Chef is useful for maintaining the servers in a known stable state for in-house datacenters. It helps to achieve infrastructure as code and helps in deployments as well. It is suitable for when there are a huge number of servers and you have to bring up the entire application stack in a safe and reliable way. It also helps in baselining the servers with same packages and corresponding versions.
Read this authenticated review
Aiman Najjar profile photo
Score 9 out of 10
Vetted Review
Verified User
Review Source
Chef is a great technology for centralized configuration management. Therefore it's perfect for configuring complex, interconnected systems where parameters may be shared, or facts (e.g. ip address,..etc) about other nodes are needed to populate configuration files. Chef provides advanced capabilities such as encrypted data bags (to store configuration variables), versioning, roles, cookbooks repositories,..etc. It's very advanced and great system for managing large and complex clusters.
  • Centralized Configuration Management; Chef really excels at that as it provides a wide range of features that are well thought of, such as data bags, encrypted data bags, roles, shared repositories, cookbooks versioning, environment locking..etc
  • Chef is based on Ruby and therefore it has all the capabilities of this powerful scripting language, unlike other tools that has its own DSL. This means greater flexibility to implement really custom logic.
  • Chef community has made an impressive progress with regards to automated testing of cookbooks.
  • Chef complexity sometimes backfires when managing large clusters. Since a node can have different sources for variables, it can easily get messy and hard to troubleshoot.
Chef is great for managing complex and interconnected ecosystems. The centralized server makes it easy to gather facts from all nodes and store all parameter in centralized repository. For example, consider a scenario where your shared, main database hostname is going to change. With Chef, you can change the data bag and it will update all applications that are using this parameter.

For simpler, quick and dirty needs. Chef overhead may not always be necessary. In those cases, Chef solo can be used but I still see other tools are more appropriate for that case.
Read Aiman Najjar's full review
Ofir Gutmacher profile photo
February 06, 2018

Chef @ SAP

Score 9 out of 10
Vetted Review
Verified User
Review Source
Chef is used as a middleware for our private managed cloud software. Chef is used in an in-house utility called Arc, that installs a Chef-agent in each server that users spin up, and then run all the cookbooks that are in the run list.

The business problems [it addresses] are: tidy up servers, control the diverse apps versions, generate a catalogue of apps and configs for the company's usage.
  • Attributes in files can be changed once, instead of walking all over the recipes.
  • Ohai - generates machine parameters non-stop.
  • Databags keep some more secured information for usage with the recipes.
  • Chef, unlike Ansible, must use its own agent. Ansible just uses the "already" pre pared "SSH" utility.
  • Engine run time - need to speed up the time for cookbooks run, like in ZEROMQ of SALTSTACK.
Well, in case we have more than 10,000 servers, and configuration must be run on them, we use Chef.
Read Ofir Gutmacher's full review
Kevin Van Heusen profile photo
Score 9 out of 10
Vetted Review
Verified User
Review Source
We use Chef for building out our environments in our development organization. It solves the problem of having a repeatable setup, once the Chef scripts are defined we can reliably deploy a similar environment as many times as needed. We don't need to guess at what we used to install on windows machines.
  • Configuration by code means that we can check in the Chef setup in a source control repository and everyone can view what changes are being made.
  • Great Windows support, Chef treats Windows as a first class customer and has great support for configuring various Windows OS properties.
  • Good documentation and support from the Chef team.
  • Chef client setup is a bit complicated, would be nice to have a streamlined installer instead of requiring command line
  • Chef user interface could be improved, would be nice to have UI options for some of the setup parameters.
  • Would be nice to be able to do one off installs/run commands. We have clients already setup talking to a server, would be a good opportunity to send commands to them.
Chef is great for ensuring you have a repeatable infrastructure. Gone are the days of manually tweaking settings and then trying to remember what you did six months later. Chef enables your team to keep tabs on what's being changed due to its ability to keep its configuration and scripts inside source control. You can look at the history of what was configured and when.
Read Kevin Van Heusen's full review
Dan Lepinski profile photo
Score 8 out of 10
Vetted Review
Verified User
Review Source
We use Chef within our Infrastructure Engineering team. Each of our cookbooks is built with the purpose of automating the deployment of a server. Our end goal is to be able to simply run Chef to build out an server with no user intervention. We currently use Chef to perform functions like, but not limited to: Adding Linux and Windows servers to Active Directory, installing IIS and creating functioning sites, installing various applications, and configuring HAProxy servers. Within a minutes, we are able to run a Knife command to build a server in our AWS account, and have that server completely functional within 30 mins.
  • Server deployment. We can knife servers within 30 minutes.
  • Automates software installs.
  • If built out correctly, it takes care of all the little configuration details Admins forget when deploying a new server.
  • There is tons of documentation out there to help you accomplish just about anything with Chef.
  • Coding experience is required. The more you know, the more you'll be able to do with Chef. Chef training is recommended.
  • Sometimes your cookbooks will break due to changes in dependencies. Not Chef's fault, but a fault with the overall path. It can be difficult to track down the issues at times.
  • Chef is overwhelming at first. There's a lot of odds and ends to take in that I found you just needed to learn with time, patience, and practice.
Chef is suited for just about any situations in which you need to automate a process on a server. Once you've built out a cookbook, the chef run with take care of everything for you. Assuming nothing changes, you never have to worry about it again. The great thing about it is it's meant to automate everything so you, and your colleagues don't have to worry about it anything. You can make changes in one cookbook that can then update an entire farm of servers.
Read Dan Lepinski's full review
No photo available
Score 7 out of 10
Vetted Review
Verified User
Review Source
I developed chef cookbooks to initially be used with provisioning our vagrant instances so that developers could have a working copy of the dev environment on their local machines. Since then, we have used chef to provision dev servers and also with packer to build images. It is primarily used with the dev team.
  • Provides a programmatic approach to automation that makes sense for developers.
  • There seems to be issues when using a cookbook on vagrant via chef solo and on a production environment being orchestrated by rightscale. Would love it if the cookbooks worked seamlessly between the two.
Depends if your operations team has a programming background. If your operations team is not well versed in programming then it might be difficult or you are working with an outdated team. Things like puppet, ansible, or even saltstack seem to be more user friendly for older operations people. Also, the learning curve for chef can be intimidating.
Read this authenticated review

About Chef

Chef is IT workload automation software from the company of the same name (formerly Opscode) in Seattle, Washington.

Chef Integrations

Chef Technical Details

Operating Systems: Unspecified
Mobile Application:No