Chef Reviews

I used the solution to transform my infrastructure into code.

The solution is easy to use and learn, and it easily automates all the code and infrastructure. The solution quickly automates development in a cloud environment and provides flexibility for selecting multiple clouds in infrastructure. The solution is easy to use.

I never faced issues with the solution’s stability.

Chef is a scalable solution.

I've worked with the solution during my three months of internship and in my self-made project. I would recommend the solution to other users.

Overall, I rate the solution an eight out of ten.

Chef is mostly for the operating systems to deploy or style, e.g. not containers. Before the containers, you need hardware, then an operating system, then you start to work on Kubernetes. To automate those steps, we use Chef.

The tool is useful for provisioning the operating system, because as you talk about the ops, sometimes customers ask to further deploy everything through automation, e.g. starting from scratch. You need to use different tools for you to provision via automation, so you need Chef. We use an automation tool such as Chef, then we were able to run Docker or containers on top of the hardware and operating system.

The features are good in Chef, especially its compliance feature. It's very good and it's what I found most valuable in the tool.

Support and pricing for Chef could be improved.

We've been dealing with and providing Chef to our customers for three years.

I'm satisfied with the stability of Chef. I'm satisfied with its performance, but it's the same with some of its competitors, e.g. there are alternatives. Ansible from Red Hat is also a good tool. We are also using it. The tool we use depends on the use case and the customer, e.g. we can use different tools.

Chef is a scalable tool.

Support for Chef could be better. It needs improvement.

The initial setup for Chef was easy. The tool is easily installed. Installation could take a few hours. It's the implementation of the tool that takes time, because if you need to scale up, you need to integrate it with other products, and that can take time.

Pricing for Chef can be relatively high for some customers but, if we consider the benefits it provides, we can say that it is a reasonable price. . Customers need to pay for the license of the tool on a yearly basis.

We were able to evaluate Terraform and Ansible.

For automation and configuration management, we are using several tools: Terraform, Chef, and Ansible for provisioning. We are using those products, and they are good. They are not for container management, but for provisioning and deploying applications, software, and hardware. We are also using them for automation.

Chef is a configuration management tool.

I can recommend Chef to others who want to start using it. I can also recommend other products, e.g. Ansible, but most of the tools which are competitors of Chef and have the same functions are also good.

I'm giving Chef a rating of seven out of ten.

It's for deployment and configuration automation.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

We use it for integration management.

The community.

The agent on the server sometimes acts finicky. 

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.

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

The technical support is very good.

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.

We have seen ROI.

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.

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.

We use it for training.

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.

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.

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

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

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

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

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.

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.

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.

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.

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.

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

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. 

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.

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.

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.

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. 

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

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.

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.

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

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

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.

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

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

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.

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.

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.

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.

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

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.

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.

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.

We have had no stability issues.

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.

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.

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.

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.

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.

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.

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.