TrustRadius Insights for Progress Chef are summaries of user sentiment data from TrustRadius reviews and, when necessary, third party data sources.
Pros
Powerful Configuration Management: Many users have found Chef to be a powerful tool for system configuration management, allowing them to efficiently manage and control the configurations of their infrastructure. With its comprehensive features and capabilities, Chef provides users with a reliable solution for ensuring consistency across their systems.
Flexible Code-Based Configuration: The use of code-based configuration in Chef has been highly praised by users for its flexibility and customizability. This feature enables users to easily define and modify configurations using code, providing greater control over their infrastructure. Additionally, the ability to track changes in a source control repository adds an extra layer of visibility and traceability.
Excellent Windows OS Support: Users appreciate Chef's excellent support for Windows OS properties, making it an ideal choice for configuring Windows systems. This robust support ensures that administrators can effectively manage and maintain their Windows servers, simplifying tasks such as software installation, configuration updates, and server deployment.
We're using Chef to deploy around 20 Linux machines that run some form of NoSQL database. We facilitate these using Chef roles and numerous cookbooks, some written in-house, and some community - depends on what is available. It's extremely powerful when making changes to a cluster environment and testing to ensure they pass tests we've implemented. Also, it makes it super easy to replace a machine if one should happen to go down. It's a real time saver compared to manually changing them one by one.
Pros
Once you have a cookbook, it can be reused or altered with ease.
Patches or swaths of changes are easy to apply to a subset of machines.
Cons
Counterintuitive when thinking about it from a scripting standpoint. e.g., it's about state and idempotence instead of scripts that can have unintended consequences.
It can cause headaches if you think about it as a scripting replacement. Both have their place, in my opinion.
Likelihood to Recommend
Once you get your head around what it's supposed to be for, it can save massive amounts of time and headache. Getting a working cookbook is the first time you get to see its value. For me, until that point, I thought Chef was a waste of time. It's very well suited for setting up and managing lots of servers that all need the same configuration, and allows for integration testing as well. I'd say it's not well suited the other way, like if you're only building one persistent machine. It would take more time to write a cookbook to set it up than just to set it up manually.
We are using Chef across many teams, both operations and development. We use Chef to manage configuration for our on-premise systems.
Pros
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.
Cons
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.
Likelihood to Recommend
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.
VU
Verified User
Engineer in Engineering (Information Services company, 501-1000 employees)
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.
Pros
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.
Cons
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.
Likelihood to Recommend
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.
VU
Verified User
Administrator in Information Technology (Computer Software company, 201-500 employees)
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.
Pros
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.
Cons
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.
Likelihood to Recommend
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.
VU
Verified User
Engineer in Engineering (Computer Software company, 1001-5000 employees)
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.
Pros
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.
Cons
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.
Likelihood to Recommend
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.
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.
Pros
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.
Cons
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.
Likelihood to Recommend
Well, in case we have more than 10,000 servers, and configuration must be run on them, we use Chef.
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.
Pros
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.
Cons
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.
Likelihood to Recommend
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.
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.
Pros
Provides a programmatic approach to automation that makes sense for developers.
Cons
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.
Likelihood to Recommend
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.
VU
Verified User
Engineer in Engineering (Media Production company, 51-200 employees)