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.
Progress Chef Reviews
8 Reviews
Enterprises (1,001+ employees)
Search is temporarily unavailable. Filters are still applied.
We are leveraging Chef Enterprise Automation stack for its numerous benefits. Chef Habitat allows us to be more agile in our application deployment and reducing the installation efforts. Chef Inspec assists with auditing to ensure that the expected changes have been applied. Chef Automate provides a single window into the status of our entire managed fleet of endpoints. These products integrate very well together and make managing multiple large datacenters a lot less effort.
Pros
Communication. The entire staff of different service areas have been very timely in communications
Helpfulness. We purchased professional services and that team was great helping with our initial onboarding
Cons
Documentation. Documentation is often confusing and trial by error typically leads to desired results
Learning curve of products. There is steep learning curve for all products offered. Could be more streamlined by less emphasis on various cli tools and more ui functionality for less experienced professionals
Likelihood to Recommend
Once the basics are understood, Chef provides a valuable tool in managing the state of systems. The integration of the various tools in the suite, while not perfect, do provide enough flexibility to cover any custom use cases. Chef seems to fit best in organizations that have experienced engineers to have some development background.
VU
Verified User
Manager in Information Technology (1001-5000 employees)
Chef is available across our enterprise and is used by certain applications. It provides a framework for our development teams to use that can create repeatable infrastructure through automated application deployments.
Pros
Excellent customer support
Broad user community
ChefConf is an excellent conference
Cons
It remains to be seen how Chef evolves after being acquired by Progress
The Chef technology itself for cookbook development has a not-insignificant learning curve due to how powerful it is
Likelihood to Recommend
Chef is a fantastic tool for automating software deployments that aren't able to be containerized. It's more developer-oriented than its other competitors and thus allows you to do more with it. The Chef Infra Server software is rock-solid and has been extremely stable in our experience. I would definitely recommend its use if you're looking for an automation framework. And it also offers InSpec which is a very good tool for testing your infrastructure to ensure it deployed as intended.
VU
Verified User
Engineer in Information Technology (10,001+ employees)
Chef is not an enterprise-wide tool. We use Chef within our department for the configuration management of our numerous servers. Even though we only have a small number of different types of servers, the configuration of hundreds of servers can be unwieldy. Having a standard recipes for a database server or reporting server has helped us to have a more consistent deployment. This helps when deploying new virtual machines, and helps with our speed to market.
Pros
System Configuration Recipes.
Configuration Management.
Cons
The recipe language could be a little more robust.
Likelihood to Recommend
Chef is a great tool to have when you need to have consistent server deployments as it offers the use of recipes and cookbooks. Because the recipe is used, the process is repeatable, and you can expect consistent deployment results. This helps prevent drift in the configuration deployments and that allows for standardization which helps for troubleshooting server and configuration issues. For me it is critical that if we deploy 7 reporting servers, that they are all configured the same, unless requirements call for them to be different. I prefer this, what we call the "Southwest model," being that Southwest Airlines uses one type of planes, 737s, albeit different variants. We prefer all of our Linux reporting boxes to be configured alike, all the same. It's the same with our database servers; they should all be the same unless we find a valid reason for them to differ. This is where the recipes are extremely helpful and valuable.
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
Likelihood to Recommend
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
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
Likelihood to Recommend
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.
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.
Pros
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.
Cons
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.
Likelihood to Recommend
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.
VU
Verified User
Engineer in Information Technology (10,001+ 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.
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.
