Chef Reviews

Once you get your head around what it's supposed to be for, it can save massive amounts of time and headache. Getting a working cookbook is the first time you get to see its value. For me, until that point, I thought Chef was a waste of time. It's very well suited for setting up and managing lots of servers that all need the same configuration, and allows for integration testing as well. I'd say it's not well suited the other way, like if you're only building one persistent machine. It would take more time to write a cookbook to set it up than just to set it up manually.

Chef is extremely valuable when there is a need to manage configurations. Chef is also becoming extremely useful for one-off changes with their chef-run tooling in Chef Workstation. Habitat is becoming increasingly beneficial for the cloud/containerized immutable world. Inspec is something companies shouldn't live without. Chef appears to be working hard to ensure that no matter the use case they have the ability to help make lives easier and more automated.

Chef is very well suited if you already have an in-house DevOps teams that have many years of experience working on Chef or related tools. Chef also works well when you need a lot of customization of the monitoring and management tool and related dashboards due to the complexity of the underlying IT. It is less appropriate for small IT environments or where internal IT expertise is limited.

Chef is a great tool to have when you need to have consistent server deployments as it offers the use of recipes and cookbooks. Because the recipe is used, the process is repeatable, and you can expect consistent deployment results. This helps prevent drift in the configuration deployments and that allows for standardization which helps for troubleshooting server and configuration issues. For me it is critical that if we deploy 7 reporting servers, that they are all configured the same, unless requirements call for them to be different. I prefer this, what we call the "Southwest model," being that Southwest Airlines uses one type of planes, 737s, albeit different variants. We prefer all of our Linux reporting boxes to be configured alike, all the same. It's the same with our database servers; they should all be the same unless we find a valid reason for them to differ. This is where the recipes are extremely helpful and valuable.

We run a large Liferay platform with a heavy load and high availability. We may have 6 developers working on the platform at a given time, and it takes them a week just to learn to set the environment up. With Chef, we can provision them a "local" environment with the push of a button.


In some instances we find Chef to be overkill. We have a large application landscape and some of our applications don't follow the traditional DTAP model (especially in systems that have serverless cloud components). We find the time it takes to write a cookbook for these systems may not provide a return on investment, especially if it isn't a critical system

Chef is great for managing large amounts of servers and ensuring that your applications run the same on all of them. While it may take a bit to learn Chef, the time saved is incredible at the end of it. However, if you are just getting into configuration management tools I would recommend looking into Ansible as it has a few key tradeoffs with Chef that can be substantial resource savers.

For our cloud-based applications with multiple environments and microservices, Chef made life easier with infrastructure as code. Along with using puppet, we can bring up or configure the environments in minutes. Any charges to services can be easily managed using recipes and cookbooks. It's easy to learn, with much less/no learning curve if you know Linux/ruby. It's flexible to manage multiple cookbooks for different environments, and works well with the puppet.

Our organization uses Chef to deploy new code in an automated fashion and it excels in this aspect. It is also well suited to updating existing configurations and push those changes in an automated fashion to large groups of servers. Having the ability to deploy simple or full system changes out to a large group of servers with little human interaction has cut down on time lost spinning up individual servers and allowed our teams to focus on other, operational problems and made us more efficient in dealing with problems with impact customers as opposed to building servers. Chef has enabled us to deploy at scale and helped grow our infrastructure as our company grows.

Chef is really great when teams are attempting to migrate over from legacy systems. In our case, it was a switch over from AIX to Linux. Thus, it was a great opportunity to use Chef to build out deployment cookbooks that could then be used win order to set up the new servers in preparation for the upgrade.

Chef is great for managing complex and interconnected ecosystems. The centralized server makes it easy to gather facts from all nodes and store all parameter in centralized repository. For example, consider a scenario where your shared, main database hostname is going to change. With Chef, you can change the data bag and it will update all applications that are using this parameter.

For simpler, quick and dirty needs. Chef overhead may not always be necessary. In those cases, Chef solo can be used but I still see other tools are more appropriate for that case.

Best tool amongst the ones I've used for CM.

Well, in case we have more than 10,000 servers, and configuration must be run on them, we use Chef.

Chef is great for ensuring you have a repeatable infrastructure. Gone are the days of manually tweaking settings and then trying to remember what you did six months later. Chef enables your team to keep tabs on what's being changed due to its ability to keep its configuration and scripts inside source control. You can look at the history of what was configured and when.

Chef is suited for just about any situations in which you need to automate a process on a server. Once you've built out a cookbook, the chef run with take care of everything for you. Assuming nothing changes, you never have to worry about it again. The great thing about it is it's meant to automate everything so you, and your colleagues don't have to worry about it anything. You can make changes in one cookbook that can then update an entire farm of servers.

Chef is useful for maintaining the servers in a known stable state for in-house datacenters. It helps to achieve infrastructure as code and helps in deployments as well. It is suitable for when there are a huge number of servers and you have to bring up the entire application stack in a safe and reliable way. It also helps in baselining the servers with same packages and corresponding versions.

Depends if your operations team has a programming background. If your operations team is not well versed in programming then it might be difficult or you are working with an outdated team. Things like puppet, ansible, or even saltstack seem to be more user friendly for older operations people. Also, the learning curve for chef can be intimidating.