Chef Reviews

• For software management
• Competitive deployment
• Upgrade

It is easy to manage on our production systems because there is an agent running on all the servers. When we want to make a change, we just make or publish our changes on the Chef server. So, it is easy to make changes to hundreds of servers in one shot. Instead of doing manually configuration, everything is automated.

Automation is everything. Having so many servers in production, many of our processes won't work nor scale. So, we look for tools to help us automate the process, and Chef is one of them.

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 stability is good.

The scalability is great.

Because we're using the open software, we never get a chance to call their support. We just use the community support. 

If you have a question, just upload your questions on the community forum, and ask for answers from there.

The integration and configuration were pretty straight forward. We have automated most of our department processes with Chef. Therefore, whenever there is a new software release ready, we can automatically use Chef to publish it to production. It is very easy to use.

We need to upgrade Chef and Ansible.

We are using the free, open source version of the software, which we are happy with at this time.

We have also used Ansible and Puppet. We have been using Ansible ever since it deployed a Docker containers with Kubernetes. We are also using Kubernetes to help manage our product assistance. 

We have our product integrated with Chef and Ansible. They are not integrated on the same system because we use two different systems. We are not using Puppet anymore.

Chef is a great tool to use. Try to automate your whole department process with Chef, if possible. Also, try to use the same tool across different platforms, so it will be easier to manage.

We use it for deployment of applications. It is a tool that you can use on the back-end for deploying architectures.

I have used the product for a couple years. I used to work for an online data center, and we used Chef for a lot of the tools and appointments.

When you are running a large cluster with hybrid applications, it can be very instrumental in making sure that they are running in sync. The tools it offers for running in environments has made it a good solution to use.

Its most valuable feature is automation.

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

We put quite a lot of stress on it, especially in our larger environments.

The scalability is good. I have used it for several environments, from small (a couple of servers) to large clusters more than 50 servers). 

We have seen a lot of ROI. Our customers really enjoy the tool. We are able to save in development time, deployment time, and it makes it easier to manage the environments.

Purchasing the solution from AWS Marketplace was a good experience. AWS's pricing is pretty in line with the product's regular pricing. Though instance-wise, AWS is not the cheapest in the market.

The AWS platform is solid. With the technologies that they offer, it makes it easy to integrate. When you are building environments and your able to integrate everything together, this is good thing.

We looked at a combination of open source and other paid solutions. It was hard because Chef offered many options that others didn't, so it wasn't a one-to-one comparison.

Chef had better functionality, flexibility, and price. It is a clean product that is easy to work with and our customers like the product.

It works well. I would highly recommend it. 

It is a well thought out product which integrates well with what developers and customers are looking for.

The product works well with VMware environments.

I have used the on-premise and AWS versions. It integrates well if you are in AWS environments. However, if you are on-premise, it may not be the best solution.

I have used in my current company for three years, and with other clients for more than ten years.

My clients are happy, which is the most important thing.

The most valuable feature is automation. 

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

We have some issues in Brazilian region with stability. However, in US region, we have no issues with stability.

Scalability is pretty good. We have nothing to complain about, except the price.

I would rate the technical support as a ten out of ten.

Amazon is a great partner.

The integration and configuration are pretty good in the AWS environment. The problems are usually on our side, not on AWS' side.

The price is always a problem. It is high. There is room for improvement. I do like purchasing on the AWS Marketplace, but I would like the ability to negotiate and have some flexibility in the pricing on it. 

I don't like some of the products offered by VMware. I like the automation offered by Chef and Puppet.

We chose Chef because some clients have some legacy systems and decided to work with them. We don't really like work with VMs, but when we have to, we use Puppet.

I have used the on-premise and AWS versions. I prefer the AWS for troubleshooting.

It integrates with many products in ILT, data management, and the server areas with each of them providing cloud computing, like EC2 and API Gateway.

We use it for provisioning and ongoing configuration management. We provision boxes with Chef by taking a base AMI that already has Chef installed, and already has the appropriate credentials to connect to the main server. Then, this will be able to roll out and deploy the configuration. In addition, it runs every five minutes, so any unexpected changes to the configuration get automatically reverted. 

This means, you get developers, who go into the box and change something, thinking it will be okay. Then, they come to you, asking "Why isn't this change that I'm making working?" We have to explain, "Because it shouldn't be going into the box in the first place."

One thing that we've been able to do is a tiered permission model, allowing developers and their managers to perform their own operations in lower environments. This means a manager can go in and make changes to a whole environment, whereas a developer with less access may only be able to change individual components or be able to upgrade the version for software that they have control over. This allows us to return some of the control back to the developers, which saves our nights and weekends.

One advantage Chef has over Ansible is your operations can be entirely headless, meaning that they can interact directly with the Chef database using shared credentials. It never uses any type of human-readable interface. Therefore, you don't have to go into a GUI nor use a command line tool. You can hit the database directly with a library.

With Ansible, a lot of the operations require that you have some type of frontward-facing tool in order for it to perform, e.g., command line or a GUI available. For a smaller scale operation, if you're managing fewer than 100 nodes, this might be fine, as it might be more helpful if you can transfer some of the power over to your developers in order to perform certain operations.

However, if you're handy enough with DSL and you can present your own front-facing interface to your developers, then you can actually have a lot more granular control with Chef in operations over what developers can perform and what they can't.

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.

It all seems to be very solid and stable.

We have rolled out around 500 nodes. Part of the reason why we have stuck with it is that it managed to effectively scale with us and stay stable at the same time.

I've contacted them before about the same issues that I have mentioned for improvement. Because Chef is being developed by a hybrid team of open source contributors, as well as the Chef core team, I am not sure my communications have gone to the right people yet.

The integration and configuration of AWS within our environment is a whole other skill set. Any configuration management or infrastructure as code will be a learning curve. Integrating it requires rearchitecting, not necessarily of the design, but certainly of the philosophy by which you approach. That is part of the benefit of it as well, you can develop a new way of thinking among the developers who will assist in producing code, which is automated, scalable, easier to write automated tests for, etc.

I don't know if it can be made easier in the adoption of it, since it is already a significant change, which is a good thing.

When we're rolling out a new server, we're not using the AWS Marketplace AMI, we're using our own AMI, but we are paying them a licensing fee.

We went the AWS route because we are fully cloud-based anyway. It was something that people who came before me were already familiar with, so it was a lot easier for me to get buy-in.

The price per node is a little weird. It doesn't scale along with your organization. If you're truly utilizing Chef to its fullest, then the number of nodes which are being utilized in any particular day might scale or change based on your Auto Scaling groups. How do you keep track of that or audit it? Then, how do you appropriately license it? It's difficult.

All you can do is communicate with them what's happening and get something that you're both comfortable with. However, if you're doing that, then what's the point of having the per-node model in the first place? It would be better to move to a fixed-pricing model.

We have also looked at Ansible, Puppet, and SaltStack. They all sort of have managed solutions which you can potentially purchase. Puppet definitely has a sort of old school thought process working behind it.

Over two to three years, we have not seen a stable release of Salt. They have some good ideas, but it isn't stable enough yet to use in a production environment.

Make sure that the operations crew has a background in Ruby, if you're going to choose Chef. If you have a Python crew, then look at Ansible as a potential option. Because I think they're catching up, and they will surpass Chef in pretty much every way sometime in the next 12 to 18 months.

Though, Chef Automate is still the most reliable solution.

At the top level, it is integrated with Terraform, which is delivering whole entities and groups of nodes. Then, those nodes are individually being provisioned with Chef. The integration is seamless.

I've run my own Chef server before. We've done completely headless with Chef Zero, where we're distributing the code directly to box during provisioning. We've used Chef pretty much every way that it can be used.

The AWS software is good. There is definitely value for somebody who is trying to understand it and be able to have a deployment of it for observation. Coming into it, there's a lot to understand, as with any technology.

If I'm thinking about coming into it now or trying to bring somebody up to speed, it would be good to have an already functioning setup of the server where you can interact with the NoSQL database and  play with some of the tools available to understanding how they work in an AWS instance. It will be very similar to the way Chef Automate works, in general. Therefore, I do see value in it. 

Our primary use case is having the properties set up across the servers. We have Chef recipes deployed and configured across our servers, so we get the same type of replication across our servers and environments.

We are using the on-premise version. We have our applications already set up for on-premise. We are using Chef and preparing it for CI/CD and other properties. Now, we are planning ahead and will use the AWS service too.

Earlier, we used to do everything manually, such as configuring the servers across different environments. Using Chef and Puppet, we can automate our CI/CD process with reduced effort from our DevOps team.

Chef recipes are easy to write and move across different servers and environments. 

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.

We do put a lot of stress on it from the QA, staging, and servers. We have a CI/CD pipeline continuously running as the developer commits the code to Chef and Puppet, which are always up and running.

The scalability is working well for our organization.

As a developer, I don't use the technical support.

We are still in the process of evaluating Chef Compute. Currently, we use Chef and Puppet. Soon, we will probably be purchasing it from AWS Marketplace.

We were already using Chef and Puppet for most of our DevOps. These were our only choices.

I would definitely recommend using Chef.

Chef integrates and configures well with AWS and other products. We use Chef and Puppet together. We are also using Splunk for log traces. We just started using Chef with AWS for easy to use containers. AWS is great for storage, CloudFormation, and CloudFrond CDN.

We are moving towards the cloud environment with all AWS resources.

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.