The solution could improve in managing role-based access. This would be helpful.

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 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.

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.

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.

Chef does not support the containerized things of Chef products. In the future, Chef could develop a docker container or docker images.

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.

Support and pricing for Chef could be improved.

Third-party innovations need improvement, and I would like to see more integration with other platforms.

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.

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.

Since we are heading to IoT, this product should consider anything related to this.

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.

The AWS monitoring, AWS X-Ray, and some other features could be improved.

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.

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.

The agent on the server sometimes acts finicky. 

I would like to see more security features for Chef and more automation.