We just raised a $30M Series A: Read our story

Chef OverviewUNIXBusinessApplication

What is Chef?

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 Enterprise Automation Stack™, a commercial distribution, is developed solely from that open source code and unifies security, compliance, infrastructure and application automation with observability. Chef provides an unequaled developer experience for the Coded Enterprise by enabling users to express infrastructure, security policies and the application lifecycle as code, modernizing development, packaging and delivery of any application to any platform. For more information, visit http://chef.io and follow @chef.

Buyer's Guide

Download the Configuration Management Buyer's Guide including reviews and more. Updated: September 2021

Chef Customers

Facebook, Standard Bank, GE Capital, Nordstrom, Optum, Barclays, IGN, General Motors, Scholastic, Riot Games, NCR, Gap

Chef Video

Archived Chef Reviews (more than two years old)

Filter by:
Filter Reviews
Industry
Loading...
Filter Unavailable
Company Size
Loading...
Filter Unavailable
Job Level
Loading...
Filter Unavailable
Rating
Loading...
Filter Unavailable
Considered
Loading...
Filter Unavailable
Order by:
Loading...
  • Date
  • Highest Rating
  • Lowest Rating
  • Review Length
Search:
Showingreviews based on the current filters. Reset all filters
MS
Senior Operations Engineer at a retailer with 10,001+ employees
Real User
It streamlined our deployments and system configurations across the board rather than have us use multiple configurations or tools

Pros and Cons

  • "You set it and forget it. You don't have to worry about the reliability or the deviations from any of the other configurations."
  • "It streamlined our deployments and system configurations across the board rather than have us use multiple configurations or tools, basically a one stop shop."
  • "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."

What is our primary use case?

It's for deployment and configuration automation.

How has it helped my organization?

It streamlined our deployments and system configurations across the board rather than have us use multiple configurations or tools, basically a one stop shop. 

You set it and forget it. You don't have to worry about the reliability or the deviations from any of the other configurations.

What is most valuable?

Its versatility is the most valuable feature. It's not necessarily the end all or be all solution for configuration management, deployment, etc. However, for what we use it for, it fits right in and it doesn't bloat our infrastructure (or any of our instances) that we deployed to.

What needs improvement?

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.

For how long have I used the solution?

Three to five years.

What do I think about the stability of the solution?

We had high uptime for it. We didn't have too many issues with the releases and the versioning that they have beeen putting out. Mostly, everything went smoothly even with major foundational changes. Overall, anytime you're doing a foundational change, there will be some growing pains, and you expect that with any tool set.

What do I think about the scalability of the solution?

Scalability is decent. Our environment has over 3200 nodes for production and lower environments. We haven't had too many problems with load or scale. When we did have issues, there were always additional resources we could deploy to scale wide or horizontally. We could also up the instant size depending on what the machines were doing.

How is customer service and technical support?

We did use technical support, but not on a regular basis. We use our contact there, our account manager, who is always readily available, if not over the phone, by email. We either open up a ticket with them or contact them directly, and they go ahead and research the issue, then get back to us with their findings.

How was the initial setup?

The integration and configuration of the product in our AWS environment was functional at the time. I didn't get to do the migration after the production environment. However, everything up until then, we had handled in our lower environments. It seemed to work as described and within the confines of what we were dealing with, and it was functional for us. I just never got to work with it in the production realm.

What was our ROI?

I have seen the ROI, but it was brief. It cut down on our workload. We supported 36 to 38 development teams with a team of six DevOps engineers. We had embedded DevOps personnel within their teams. It could have gotten to the point where we needed individual DevOps personnel for every team, but Chef allowed us, as a group of five, depending on the time we were there, to reach out to them individually, and help them on a one-to-one basis. At the same time, we provide a center of excellence for best practices. This easily could've scaled to each team needing their own direct support person, but with the ability to manage these configurations through Chef, it allowed us to hand them their best practices straight across the board. Therefore, we didn't have to go ahead and drop in on each team and help them through their migration practice.

Which other solutions did I evaluate?

We also looked at Puppet, Ansible, and Jenkins. Chef rolled things into one for us with the way that they were running their deployments.

It was more of a one stop convenience going with Chef. A lot of the features, plugins, and compatibility items that we were looking for were already bundled into the package. Rather than piecemeal things together with the other services, we directly went with Chef to make sure it was a smooth, functional package for us. We went with Chef and its suite of tools to manage things more centrally.

What other advice do I have?

Make sure when you are tooling that what you are trying to create is functional within the product. Don't try and make it do something that it's not technically, nor architecturally, designed to do. While there are corner cases for things like that, if you're going to start to wander down that road, maybe you better take another look at a wider set of tools rather than just the one that you've got your eye on or the one your executives have their eyes on.

The product is functional. The ease of setup for almost everything that we did tooling-wise was straightforward. We didn't have too many issues which were out of the ordinary, corner case scenarios when using the product. That's always a bonus. Especially in ease of the installation and configuration, it is always a good thing when you're dealing with a product like this.

It integrates with softer packages, modern packages, alerting packages, etc. Aside from the base infrastructure, there are a lot of Chef tooling and plugins which make it a rather straightforward addition to the tool set. Almost everything was off-the-shelf or out-of-the-box. We did not have to configure or rewrite it ourselves, which was a big bonus. Most of these products are usually commercialized and available with ready support and tooling. 

There was a migration that we were moving to the AWS sphere, but I was only doing that in the migration phase, never into the full operational phase. Comparability-wise, you do have a more control over your on-premise stuff because you can customize it to your needs. There is plenty of functionality that you can get in when you have on-premise. Though, you have to follow the standards when you're dealing with a vendor provided service.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
AS
Solutions Architect with 201-500 employees
Real User
The scalability and technical support are very good

What is our primary use case?

We use it for integration management.

What is most valuable?

The community.

What needs improvement?

The agent on the server sometimes acts finicky. 

For how long have I used the solution?

One to three years.

What do I think about the stability of the solution?

It is stable most of the time. There hasn't been any downtime. We did not go with the traditional architecture, so we decided to use the AWS systems by decoupling the traditional architecture.

What do I think about the scalability of the solution?

The scalability of the product is quite nice. We have deployed it across six to seven organizations.

How is customer service and technical support?

The technical support is very good.

How was the initial setup?

The integration and…

What is our primary use case?

We use it for integration management.

What is most valuable?

The community.

What needs improvement?

The agent on the server sometimes acts finicky. 

For how long have I used the solution?

One to three years.

What do I think about the stability of the solution?

It is stable most of the time. There hasn't been any downtime.

We did not go with the traditional architecture, so we decided to use the AWS systems by decoupling the traditional architecture.

What do I think about the scalability of the solution?

The scalability of the product is quite nice. We have deployed it across six to seven organizations.

How is customer service and technical support?

The technical support is very good.

How was the initial setup?

The integration and configuration in our AWS environment is very good.

It works well with most operation management systems, and where it doesn't, we upgrade the system.

What was our ROI?

We have seen ROI.

Which other solutions did I evaluate?

We tried Ansible and Jenkins. However, because we use Terraform in our products, these weren't the most fitting solutions. Chef was the best solution for helping us build our infrastructure.

What other advice do I have?

Find use cases and do your research.

We only use the AWS version. We tried the other versions, but we found that they were lacking in functionality.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Find out what your peers are saying about Chef, Microsoft, Red Hat and others in Configuration Management. Updated: September 2021.
541,108 professionals have used our research since 2012.
BP
AWS Content Support Manager at a tech company with 51-200 employees
Real User
Great for configuration management and integration, especially in AWS

Pros and Cons

  • "The most valuable feature is the language that it uses: Ruby."
  • "I would like to see more security features for Chef and more automation."

What is our primary use case?

We use it for training.

How has it helped my organization?

All the Chef enthusiasts who come to us to learn and train, improve their skillsets to get jobs. It's a really easy product in AWS. It's easy to teach and easy to understand.

What is most valuable?

The most valuable feature is the language that it uses: Ruby.

Regarding integration and configuration of the product, they're pretty manageable. The layers are really easy to configure.

What needs improvement?

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

What do I think about the stability of the solution?

It's working great. It's stable. We try to produce real-world scenarios with the students as much as possible.

How was the initial setup?

 It's a really easy product in AWS. It's easy to teach and easy to understand.

Which other solutions did I evaluate?

We considered Puppet and Ansible. We went with Chef because Chef uses Ruby and Ruby is pretty popular right now.

What other advice do I have?

Compare it to the other services that you use.

Everything can always be improved. If you have a specific need in configuration management and integration, Chef is a great product, especially with AWS.

Disclosure: My company has a business relationship with this vendor other than being a customer: Partner.
IH
Manager at ZS Associates
Real User
Simple, easy to use, more versatile, can handle a hundred thousand servers at the same time

Pros and Cons

  • "This solution has improved my organization in the way that deployment has become very quick and orchestration is easy. If we have thousands of servers we can easily deploy in a small amount of time. We can deploy the applications or any kind of announcements in much less time."
  • "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."

What is our primary use case?

Our primary use case of this solution is for the orchestration of the service deployment, and integrations. Earlier, we had it on-prem but now it's totally on AWS cloud. AWS cloud is easier to use, and changing and refitting the architecture solutions is very easy.

How has it helped my organization?

This solution has improved my organization in the way that deployment has become very quick and orchestration is easy. If we have thousands of servers we can easily deploy in a small amount of time. We can deploy the applications or any kind of announcements in much less time. 

We started using the AWS services, for example, Opsware. Whatever recipes we have written in SAP, we can use the same recipe in Opsware. Moving from one to the other is almost no work.

What is most valuable?

The most valuable features for us would be the writing of the recipes. Any business can write the recipe based on their deployment, it's not like we have to follow a specific path. 

AWS Marketplace gives you a sense of authentic products. Since AWS does its own checks on the marketplace products it's kind of a sense of relief that something will not be problematic.

What needs improvement?

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.

For how long have I used the solution?

Three to five years.

What do I think about the stability of the solution?

It's quite stable, we hardly see surprises. Its deployment is very smooth.

What do I think about the scalability of the solution?

We have many applications and each one has its own cluster of the servers. We have more than a hundred servers and a couple of clusters which is a big environment. We use SAP and they help us. 

How are customer service and technical support?

If we need technical support we raise an AWS ticket and someone from the technical support team helps us. If we hit a roadblock we have to go out beyond AWS support which is fine.

Which solution did I use previously and why did I switch?

The reason that we chose this solution is because it's more effective and it gives us the ability to do the customization that we would like to do. It's also more versatile in the way that we can deploy using this tool, not only on Cloud but at the same time on-prem as well. It's more powerful.

What was our ROI?

We see ROI from saving a lot of time and that our deliveries are now on time. Also, we save the amount of time we take to deploy and make any changes in the deployment and in expediting service. The amount of time invested there is less which in turn we can invest in some other work. So our ROI is speed.

What other advice do I have?

I would rate this solution a nine because it's simple, easy to use, more versatile, and most importantly, it can handle the hundred thousand servers at the same time very easily and almost in no time.

It depends on the enterprise need, but I would advise someone considering this solution that if you want to have very heavy or big clusters this is a product you can trust for deployment and it's smooth. You can create your own custom recipe which in other products, I would say is only partially there and depends on the different types of applications. Not all applications have the same deployment and orchestration patterns and most of the SAP deployment credits are covered. 

Disclosure: I am a real user, and this review is based on my own experience and opinions.
AC
Primary Architect at Autodesk, Inc.
Real User
It is simple, easy to use, and versatile

Pros and Cons

  • "The most important thing is it can handle a 100,000 servers at the same time easily with no time constraints."
  • "Deployment has become quick and orchestration is now easy."
  • "Since we are heading to IoT, this product should consider anything related to this."

What is our primary use case?

It is for orchestrating our servers and deployments to do integrations.

How has it helped my organization?

Deployment has become quick and orchestration is now easy. If you have thousand of servers, you can easily deploy them in a minimum amount of time. You can deploy applications or any type of announcements in a reduced amount of time.

What is most valuable?

Writing recipes, which is great. Any business can write a recipe based on their deployment. We do not have to follow a path.

It is simple, easy to use, and versatile. The most important thing is it can handle a 100,000 servers at the same time easily with no time constraints.

What needs improvement?

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

For how long have I used the solution?

Three to five years.

What do I think about the stability of the solution?

The product is quite stable. We hardly experience any surprises. Its deployment is very smooth.

What do I think about the scalability of the solution?

We have many applications and each is having its own cluster of the service. We have more than a 100 servers and a couple of clusters. That is a big environment.

How is customer service and technical support?

If we need help, we raise an AWS ticket. Then, the AWS support helps us with the technical support.

How was the initial setup?

The integration and configuration of this product in our AWS environment was simple.

What was our ROI?

We are saving a lot our delivery time and on te amount of the time that we deploy. We used to make changes during the deployment. So, the amount of time invested there is less, which in turn, we can invest in some other work. Therefore, our ROI is quick, though it does depend on the size of your service.

What's my experience with pricing, setup cost, and licensing?

Purchasing through the AWS Marketplace was a good place to go to purchase this product because you receive a sense of authenticity with the products. Since AWS has its own checks on AWS Marketplace products, there is sense of relief that the product will not be problematic.

Which other solutions did I evaluate?

We looked at other product like Puppet. We are also using Ansible. However, Chef is the market leader, so we went with that.

Chef is more effective. It provides the hooks, so we can do customization. The product is more versatile. For example, we can deploy using this tool, not only with cloud, but simultaneously on-premise. So, it is quite powerful.

What other advice do I have?

If someone would like to go for a heavy cluster, this is a product they can trust for deployment, since it is smooth. Even though customization is needed, they can create their own custom recipe, which in other products, I would say is partially there and also depends on the different type of applications. 

We had the solution on on-premise for a year, but now it is completely on AWS Cloud. AWS Cloud is easier to use. We can change the solution by refitting the architecture solution now because it is easy.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
TR
Engineer II at a transportation company with 10,001+ employees
Real User
We have had less production issues since using it to automate our provisioning

Pros and Cons

  • "It has been very easy to tie it into our build and deploy automation for production release work, etc. All the Chef pieces more or less run themselves."
  • "We have had less production issues since using Chef to automate our provisioning."
  • "There is a slight barrier to entry if you are used to using Ansible, since it is Ruby-based."

What is our primary use case?

We use it for provisioning Adobe Experience Manager web application environments.

How has it helped my organization?

It has given us more resiliency in all the stuff we now manage with Chef, which was previously sort of manually maintained. Now, we are able to drive all of that through version control and automation, which is a lot faster.

What is most valuable?

It has been very easy to tie it into our build and deploy automation for production release work, etc. All the Chef pieces more or less run themselves.

What needs improvement?

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.

For how long have I used the solution?

One to three years.

What do I think about the stability of the solution?

We have had no stability issues.

What do I think about the scalability of the solution?

The scalability works. We haven't scaled it too high. We have a few different servers in different places. 

We have been looking into the high availability offering, but we haven't actually stood it up yet. We are hopeful about it though.

How are customer service and technical support?

We have had to open a few Amazon support tickets. However, they have typically not been Chef-related, they have been Amazon service-related.

The technical support has been great. Our tickets have all been closed out quickly.

Which solution did I use previously and why did I switch?

Our environments used to be on-premise, then we were moving them into the cloud. Since they were big and complicated, we decided we needed a manageable provisioning system instead of doing it by hand every time.

What was our ROI?

We have seen ROI. It has decreased a lot of man-hours that we were previously spending doing stuff which we now manage with Chef. It has decreased when we have a production issue, since we are able to fix it faster. We also have had less production issues since using Chef to automate our provisioning.

What's my experience with pricing, setup cost, and licensing?

I wasn't involved in the purchasing, but I am pretty sure that we are happy with the current pricing and licensing since it never comes up.

Which other solutions did I evaluate?

We considered Chef, Puppet, Ansible, and homegrown solutions. We had a couple people who used to use Ansible and some people who had previously used Chef. I think we just settled on Chef after trying it because we liked that it was Ruby-based, and there were a lot of community cookbooks already. This lined up parallel with what we wanted to be doing.

What other advice do I have?

I would recommend Chef. It is very user-friendly. There are a lot of community resources which make it easy to onboard. It also plays nicely with existing automation tools and other things which you are probably already using.

Chef works with Adobe Experience Manager, Terraform, and AWS CLI tools. We have been pleased with the integration.

We have only used the AWS offering.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
TW
DevOps Director at a tech vendor with 501-1,000 employees
MSP
It is easy to manage on our production systems because there is an agent running on all the servers

Pros and Cons

  • "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."
  • "If they can improve their software to support Docker containers, it would be for the best."

What is our primary use case?

  • For software management
  • Competitive deployment
  • Upgrade

How has it helped my organization?

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.

What is most valuable?

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.

What needs improvement?

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.

For how long have I used the solution?

Three to five years.

What do I think about the stability of the solution?

The stability is good.

What do I think about the scalability of the solution?

The scalability is great.

How is customer service and technical support?

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.

How was the initial setup?

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.

What's my experience with pricing, setup cost, and licensing?

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

Which other solutions did I evaluate?

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.

What other advice do I have?

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.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Stefan Nava
Director at a comms service provider with 10,001+ employees
Real User
When you are running a large cluster with hybrid applications, it can be very instrumental in making sure that they are running in sync

Pros and Cons

  • "It is a well thought out product which integrates well with what developers and customers are looking for."
  • "Third-party innovations need improvement, and I would like to see more integration with other platforms."

What is our primary use case?

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.

How has it helped my organization?

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.

What is most valuable?

Its most valuable feature is automation.

What needs improvement?

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

For how long have I used the solution?

One to three years.

What do I think about the stability of the solution?

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

What do I think about the scalability of the solution?

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

What was our ROI?

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.

What's my experience with pricing, setup cost, and licensing?

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.

Which other solutions did I evaluate?

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.

What other advice do I have?

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.

Disclosure: My company has a business relationship with this vendor other than being a customer: Partner.
JB
CTO at FCamara
Real User
It integrates with many products in ILT and data management areas with each of them providing cloud computing

Pros and Cons

  • "The most valuable feature is automation."
  • "The AWS monitoring, AWS X-Ray, and some other features could be improved."

What is our primary use case?

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

How has it helped my organization?

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

What is most valuable?

The most valuable feature is automation. 

What needs improvement?

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

For how long have I used the solution?

More than five years.

What do I think about the stability of the solution?

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

What do I think about the scalability of the solution?

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

How is customer service and technical support?

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

Amazon is a great partner.

How was the initial setup?

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

What's my experience with pricing, setup cost, and licensing?

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. 

Which other solutions did I evaluate?

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.

What other advice do I have?

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.

Disclosure: My company has a business relationship with this vendor other than being a customer: Partner.
Wil Whitlark
Lead DevOps Engineer at General Assembly
Real User
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.

Pros and Cons

  • "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."
  • "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."
  • "There appears to be no effort to fix the command line utility functionality, which is definitely broken, provides a false positive for a result when you perform the operation, and doesn't work."

What is our primary use case?

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

How has it helped my organization?

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.

What is most valuable?

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.

What needs improvement?

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.

For how long have I used the solution?

More than five years.

What do I think about the stability of the solution?

It all seems to be very solid and stable.

What do I think about the scalability of the solution?

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.

How is customer service and technical support?

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.

What about the implementation team?

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.

What's my experience with pricing, setup cost, and licensing?

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.

Which other solutions did I evaluate?

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.

What other advice do I have?

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. 

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Sharath Annabathina
Senior Software Engineer at BMS
Real User
Its recipes are easy to write and move across different servers and environments. However, they need to provide better functionalities when creating recipes.

Pros and Cons

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

What is our primary use case?

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.

How has it helped my organization?

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.

What is most valuable?

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

What needs improvement?

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.

For how long have I used the solution?

Less than one year.

What do I think about the stability of the solution?

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.

What do I think about the scalability of the solution?

The scalability is working well for our organization.

How is customer service and technical support?

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

What's my experience with pricing, setup cost, and licensing?

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.

Which other solutions did I evaluate?

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

What other advice do I have?

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.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
MH
Head of Tools and Automation for Infrastructure at a tech services company with 1,001-5,000 employees
Real User
Provides a centralized management system in a hybrid cloud environment, but needs more analytics and reporting

Pros and Cons

  • "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."
  • "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."
  • "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."
  • "Vertical scalability is still good but the horizontal, adding more technologies, platforms, tools, integrations, Chef should take a look into that."

What is our primary use case?

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.

How has it helped my organization?

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.

What is most valuable?

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.

What needs improvement?

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.

For how long have I used the solution?

One to three years.

What do I think about the stability of the solution?

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

What do I think about the scalability of the solution?

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.

How are customer service and technical support?

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.

Which solution did I use previously and why did I switch?

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

How was the initial setup?

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.

What's my experience with pricing, setup cost, and licensing?

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.

Which other solutions did I evaluate?

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.

What other advice do I have?

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.

Disclosure: My company has a business relationship with this vendor other than being a customer: Partner.
ITCS user
Senior DevOps Engineer at a tech services company with 1,001-5,000 employees
MSP
Enabled us to completely eliminate manual deployments

Pros and Cons

  • "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."
  • "If only Chef were easier to use and code, it would be used much more widely by the community."

What is our primary use case?

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.

How has it helped my organization?

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.

What is most valuable?

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.

What needs improvement?

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.

What other advice do I have?

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.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Buyer's Guide
Download our free Configuration Management Report and find out what your peers are saying about Chef, Microsoft, Red Hat, and more!