Chef Reviews

My primary use case for Chef has been always for infrastructure provisioning. For example, infrastructure as a cloud, provisioning it in a multi-cloud environment. That's predominantly what we're using Chef for.

I wanted to monitor a hybrid cloud environment, one using AWS and Azure. If I have to provision/orchestrate between multiple cloud platforms, I can use Chef as a one-stop solution, to broker between those cloud platforms and orchestrate around them, rather than going directly into each of the cloud-vendors' consoles. It works like a centralized broker/control management solution, which has helped broker in a hybrid cloud environment. AWS and Azure just two examples. This cloud platform keeps expanding.

The best are some of the default, out-of-the-box capabilities that are available. Plug-ins with multiple vendors and other infra-cloud platforms. The templates are very easy to use. Ease of use, overall, is an advantage of Chef.

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.

I have had minor issues with development and configuration but we have an in-house team that takes care of most of it.

My scaling is taken care of, predominantly, with the native capabilities with my cloud. Most of our environments are cloud-first companies, so that has not been much of a challenge.

When I start adding more engines to it, so far I haven't faced issues because I have a different level of scaling up. But in terms of horizontal scalability, like adding more technology, for instance, I think Chef has a ways to go. Vertical scalability is still good but the horizontal, adding more technologies, platforms, tools, integrations, Chef should take a look into that.

Vendor support has been decent. It's okay from that perspective. But sometimes it takes a while. They could have more dedicated support. Sometimes that is a challenge. If my in-house team cannot handle it, getting dedicated vendor support is a challenge and something that comes at a premium. Because they charge us a premium, I use my partner's channel rather than directly with Chef. Except for some proofs of concept and some demos, I haven't used much help.

But presale support was very good.

I mostly wrote scripts, predominantly with Python and some others. Compared them, Chef has definitely been more satisfactory.

Setting up initially was quite straightforward. What was challenging was when our platforms kept changing. We had an on-premise environment and we evolved to the cloud world. Then there was AWS and Azure. We keep adding and expanding. Maybe we haven't thought much about our architecture - that's been through some changes. And maybe the horizontal capabilities I was talking about earlier, the scalability might be another aspect. But the initial setup itself was quite straightforward.

There are some flexible pricing models which you get from multiple partners, and then we bundle our solution. From that perspective, it is okay so far. But maybe when we go to the enterprise level, there will be components we have to pay for, when it comes to DevOps with customers who already have an existing license. Those things are always complicated. But otherwise, for regular commercial licensing, it can be flexible.

We used SPO Orchestrator. And before Chef there was one proof of concept with Puppet but for some reason, Puppet was not as developer-oriented. Many of our in-house people found Chef to be more user-friendly, from an administrative perspective, so we narrowed it down to Chef.

If you're looking for an environment where there is an ROI business case, or looking into or orchestrating multiple environments, it makes sense to go with Chef. But if it's a minor orchestration you're looking into, the best tool would always be native solutions. In other words, if I you are looking at a platform where there will be two or three moving parts, you should look at the platform's built-in, native solution. If you have a wider range of moving parts and automation to be done, configuration-wise, you can bring in an orchestrator like Chef.

I used Chef for server provisioning in AWS using the knife-aws plugin.

I also used Chef as a configuration management tool. It did all the setup and configuration for all the software packages for multiple servers. To make any updates to the server setups, all we did was update the recipes on the Chef Server.

Manual deployments came to a halt completely. Server provisioning became lightning fast. Chef-docker enabled us to have fewer sets of source code for different purposes. Configuration management was a breeze and all the servers were as good as immutable servers.

Configuration management is the most useful feature and is used by everyone. Provisioning is also an important feature. Since Chef collects a lot of inventory using Ohai, the inventory can also be used to integrate with third-party tools.

Although deployment can be done a lot better with other tools on the market, Chef also accomplishes this. However, remember that rollback can be problematic here.

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 an extremely amazing tool and has been extensively developed in the last couple of years. There are tons of plugins and integrations available for it, my favorite being the Chef-docker plugin.

I started with Chef as a QA engineer and wrote some beginner level recipes for some easy setups on AWS. I then worked on a bank project where I used the knife-vcloud plugin for Chef to automate provisioning for VMware vCloud. I did some initial evaluation, comparing Chef and Ansible for SAP to automate deployment on bare metal. In some recent projects, I wrote Chef recipes for deployment automation. I integrated it with Fabric/Python. 

I would definitely rate Chef an eight out of 10. Although Chef is easy to code, it still has a little learning curve, since you need to know Ruby.

Chef is a configuration management tool, and I work for the product team of Chef. All the DevOps teams mainly use Chef for configuration management of their servers or infrastructure.

Chef is a great tool for an automation person who wants to do configuration management with infrastructure as a code.

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

I have been using Chef for four years.

I rate Chef a nine out of ten for stability.

Thousands of customers are using the solution.

I rate Chef a nine out of ten for scalability.

The solution's technical support team is really good, and you can directly contact them regarding any issues.

Positive

The solution's initial setup for clients is very easy, but it is moderate for the infra server. The solution's documentation is very good, and its installation can be done in 15 to 20 minutes.

Chef is priced based on the number of nodes.

Overall, I rate Chef a nine out of ten.