DevOps Engineer at a comms service provider with 501-1,000 employees
Real User
Top 5
2023-11-16T10:35:48Z
Nov 16, 2023
I did not like the solution. It is an old technology. Compared to Ansible, it just doesn't hold up because we need to deploy a client to each of the services we need to manage, which makes the automation much harder.
DevOps Engineer at a manufacturing company with 1,001-5,000 employees
Real User
Top 5
2023-09-18T15:42:00Z
Sep 18, 2023
In terms of improvement, Chef could get better by being more widely available, adapting to different needs, and providing better documentation. There is also an issue with shared resources like cookbooks lacking context, which could lead to problems when multiple companies use them. Chef should aim for wider availability, better flexibility, clearer documentation, and improved management of shared resources to prevent conflicts. Many companies are now moving to Ansible, so I would recommend better documentation, easier customer use, and simpler integration. I have concerns about the complexity of migrating to different servers and would prefer a simpler process.
Right now, we are moving towards a container department with Docker and Kubernetes, so I'm not sure if Chef has features to support containers. I haven't really researched it yet, but if they can improve their software to support Docker containers, it would be for the best.
Senior Operations Engineer at a retailer with 10,001+ employees
Real User
2018-12-11T08:31:00Z
Dec 11, 2018
The compatibility with the different platforms that we are using needs improvement. We are mainly a Linux shop, but for a lot of ancillary Windows services that we were bringing in from vendors of third-party customers and things that we are using for the supply chain that we were running, Chef did not necessarily fit across the board for what we are doing there. In-house, the product has been pretty functional for us. I would like them to add database specific items, configuration items, and migration tools. Not necessarily on the builder side or the actual setup of the system, but more of a migration package for your different database sets, such as MongoDB, your extenders, etc. I want to see how that would function with a transition out to AWS for Aurora services and any of the RDBMS packages. If there was something that was automated rather than through the package of the database system itself, this might aid us for a lot of DR stuff, resiliency, multi-region, etc. Especially when consolidating from a lot of on-premise stuff to cloud services, this functionality might improve our rate of deployment.
Engineer II at a transportation company with 10,001+ employees
Real User
2018-12-11T08:31:00Z
Dec 11, 2018
There is a slight barrier to entry if you are used to using Ansible, since it is Ruby-based. However, it is just a different product and requires you to acclimate yourself, just like any other product would.
I would rate this solution a nine because our use case and whatever we need is there. Ten out of ten is perfect. We have to go to IOD and stuff so they should consider things like this to make it a ten.
One of the biggest things that I miss is in Chef 11 and earlier, organizations were able to be managed directly through the Chef control command line utility. Now, while we prefer to interact directly with the database, there is still some value in being able to have access to the command line utility. While that functionality is still present and in the documentation, it has been broken since Chef 12. We are now looking at Chef 14, and they already have Chef 15 in the pipeline, but there appears to be no effort to fix this functionality, which is definitely broken, provides a false positive for a result when you perform the operation, and doesn't work. It would be nice to have an update to Chef Zero, such that it was more geared toward containers. Before Docker took hold, there was something called Chef Zero Vagrant, which was a plugin for Vagrant which would provision your developer's local copies of their environment for local testing. This was great for the technology, but we haven't seen an evolution of it now that the containerization technology has moved forward.
They could provide more features, so the recipes could be developed in a simpler and faster way. There is still a lot of room for improvement, providing better functionalities when creating recipes. We would also like more recipes. This is key for us.
The time that it takes in terms of integration. Cloud integration is comparatively easy, but when it comes to two-link based integrations - like trying to integrate it with any monitoring tools, or maybe some other ticketing tools - it takes longer. That is because most of the out-of-the-box integration of the APIs needs some revisiting. They should make it into a larger toolset. I would also like to see more analytics and reporting features. Currently, the analytics and reporting features are limited. I'll have to start building my own custom solution with Power BI or Tableau or something like that. If it came with built-in analytics and reporting features that would be great.
Senior DevOps Engineer at a tech services company with 1,001-5,000 employees
MSP
2018-07-01T08:03:00Z
Jul 1, 2018
In my presentation to SAP engineering, Ansible was chosen over Chef by all the admins for one reason: simplicity. If only Chef were easier to use and code, it would be used much more widely by the community.
Chef, is the leader in DevOps, driving collaboration through code to automate infrastructure, security, compliance and applications. Chef provides a single path to production making it faster and safer to add value to applications and meet the demands of the customer. Deployed broadly in production by the Global 5000 and used by more than half of the Fortune 500, Chef develops 100 percent of its software as open source under the Apache 2.0 license with no restrictions on its use. Chef...
Chef does not support the containerized things of Chef products. In the future, Chef could develop a docker container or docker images.
I did not like the solution. It is an old technology. Compared to Ansible, it just doesn't hold up because we need to deploy a client to each of the services we need to manage, which makes the automation much harder.
In terms of improvement, Chef could get better by being more widely available, adapting to different needs, and providing better documentation. There is also an issue with shared resources like cookbooks lacking context, which could lead to problems when multiple companies use them. Chef should aim for wider availability, better flexibility, clearer documentation, and improved management of shared resources to prevent conflicts. Many companies are now moving to Ansible, so I would recommend better documentation, easier customer use, and simpler integration. I have concerns about the complexity of migrating to different servers and would prefer a simpler process.
The solution could improve in managing role-based access. This would be helpful.
Support and pricing for Chef could be improved.
Right now, we are moving towards a container department with Docker and Kubernetes, so I'm not sure if Chef has features to support containers. I haven't really researched it yet, but if they can improve their software to support Docker containers, it would be for the best.
I would like to see more security features for Chef and more automation.
Third-party innovations need improvement, and I would like to see more integration with other platforms.
The compatibility with the different platforms that we are using needs improvement. We are mainly a Linux shop, but for a lot of ancillary Windows services that we were bringing in from vendors of third-party customers and things that we are using for the supply chain that we were running, Chef did not necessarily fit across the board for what we are doing there. In-house, the product has been pretty functional for us. I would like them to add database specific items, configuration items, and migration tools. Not necessarily on the builder side or the actual setup of the system, but more of a migration package for your different database sets, such as MongoDB, your extenders, etc. I want to see how that would function with a transition out to AWS for Aurora services and any of the RDBMS packages. If there was something that was automated rather than through the package of the database system itself, this might aid us for a lot of DR stuff, resiliency, multi-region, etc. Especially when consolidating from a lot of on-premise stuff to cloud services, this functionality might improve our rate of deployment.
The agent on the server sometimes acts finicky.
There is a slight barrier to entry if you are used to using Ansible, since it is Ruby-based. However, it is just a different product and requires you to acclimate yourself, just like any other product would.
I would rate this solution a nine because our use case and whatever we need is there. Ten out of ten is perfect. We have to go to IOD and stuff so they should consider things like this to make it a ten.
The AWS monitoring, AWS X-Ray, and some other features could be improved.
Since we are heading to IoT, this product should consider anything related to this.
One of the biggest things that I miss is in Chef 11 and earlier, organizations were able to be managed directly through the Chef control command line utility. Now, while we prefer to interact directly with the database, there is still some value in being able to have access to the command line utility. While that functionality is still present and in the documentation, it has been broken since Chef 12. We are now looking at Chef 14, and they already have Chef 15 in the pipeline, but there appears to be no effort to fix this functionality, which is definitely broken, provides a false positive for a result when you perform the operation, and doesn't work. It would be nice to have an update to Chef Zero, such that it was more geared toward containers. Before Docker took hold, there was something called Chef Zero Vagrant, which was a plugin for Vagrant which would provision your developer's local copies of their environment for local testing. This was great for the technology, but we haven't seen an evolution of it now that the containerization technology has moved forward.
They could provide more features, so the recipes could be developed in a simpler and faster way. There is still a lot of room for improvement, providing better functionalities when creating recipes. We would also like more recipes. This is key for us.
The time that it takes in terms of integration. Cloud integration is comparatively easy, but when it comes to two-link based integrations - like trying to integrate it with any monitoring tools, or maybe some other ticketing tools - it takes longer. That is because most of the out-of-the-box integration of the APIs needs some revisiting. They should make it into a larger toolset. I would also like to see more analytics and reporting features. Currently, the analytics and reporting features are limited. I'll have to start building my own custom solution with Power BI or Tableau or something like that. If it came with built-in analytics and reporting features that would be great.
In my presentation to SAP engineering, Ansible was chosen over Chef by all the admins for one reason: simplicity. If only Chef were easier to use and code, it would be used much more widely by the community.