Chef IT infrastructure automation suites were developed by Chef Software in Seattle and acquired by Progress Software in September 2020. The Chef Enterprise Automation Stack is an integrated suite of automation technologies presented as a solution for delivering change quickly, repeatedly, and securely over every application's lifecycle. The Chef Effortless Infrastructure Suit is an integrated suite of automation technologies to codify infrastructure, security, and compliance, as well as…
N/A
Puppet Enterprise
Score 8.9 out of 10
N/A
Puppet Enteprise is an IT automation and configuration management solution that enables users to manage and automate infrastructure and complex workflows. The vendor states Puppet Enterprise combines both model‑based and task-based capabilities in a way that enables organizations to scale their multi-cloud infrastructure as their automation footprint grows, with more flexibility from both agent-based and agentless capabilities.
N/A
Ansible
Score 9.2 out of 10
N/A
The Red Hat Ansible Automation Platform (acquired by Red Hat in 2015) is a foundation for building and operating automation across an organization. The platform includes tools needed to implement enterprise-wide automation, and can automate resource provisioning, and IT environments and configuration of systems and devices. It can be used in a CI/CD process to provision the target environment and to then deploy the application on it.
We considered the three leading competitors in the field: Chef, Puppet and Ansible. Ansible is a very strong competitor and has a nice degree of flexibility in that it does not require a client install. Instead the configuration is delivered by SSH which is very simple. Puppet …
Chef is the more developer-oriented of the three main tools in this space. It has a steeper learning curve as a result but it allows you to do more. Puppet seems to be more geared towards automated the management of the operating system. Ansible is an excellent tool but …
Puppet Labs and CFEngine are also open source and competes with Chef. Chef has more support from the community with templates available for large scale IT deployments. RedHat Ansible is better suited when you are already using RedHat OS and OpenShift since it comes as it comes …
Briefly looked into Puppet but ended up going with Chef because a colleague had experience with it instead. Didn't get far enough into a deployment to even really compare the two.
Vice President, Chief Architect, Development Manager and Software Engineer
Chose Progress Chef
We found that Chef was easy to use, and we liked the whole concept of recipes and cookbooks. We were using the concept of recipes and cookbooks for our SQL development, so Chef was a natural fit for our team members and environment. That whole paradigm is easy for everyone …
I've mostly explained the differences between Ansible and Chef in my previous answers. I generally prefer Chef over Ansible because the platforms we use have very convenient cookbooks.
Chef is easy to install and manage, and the learning curve is minimal, as most of the engineers are already aware of the syntax to configure services. With flexible crating recipes and cookbooks, Chef made our jobs easier, and also it integrates well with Puppet. Overall …
Chef is something we have been using for a while, so it is the natural choice when training new engineers to maintain our systems. If I was to choose a configuration management tool now, I would pick Ansible mainly because of its agentless nature and YAML cookbook language …
We believe Chef is a great tool for DevOp. It works really well with repository tools such as Bitbucket and artifactory. The other products we evaluated either were too pricey or did not have the support we needed for a company that was very vanilla with automation. We selected …
We were evaluating Ansible as it was agent less, SSH based, simple to use and is completely based on SSH protocol. As and when the servers count increase the performance might degrade. One main disadvantage with Ansible is it is more suitable for linux based systems where SSH …
I really found that Chef to be much friendlier and innovative than Puppet. There is an opinion in the DevOps community that says that Chef is friendlier to programmers whereas Puppet is friendlier to system administrators. This might be true, as I do come from development …
Chef is good for organizations with many servers, because of the client-server approach. I guess Ansible can be used for some 20-40 servers, just ssh and run the playbook. Chef is in ruby which is a really simple to learn language as opposed to competitiors.
Chef was easier to setup than Puppet. It also has better Windows support and documentation. Reading through the Chef documentation gave good examples on how to configure things for Windows environments, however Puppet was a bit lacking in that regard. Puppet has better support …
Ansible and salt stack seem to be the new cool kids on the block because they are easier to setup and manage across smaller teams. I think the use of puppet is dying down in favor for these new technologies. I would like to see chef use cases with simpler implementation.
As I mentioned before Ansible is a great tool. There is no question about it. It has very simple syntax (YAML), is very easy to learn, and is scalable as well. But the only thing that Ansible lacked at that time was the actual agent that have to go into each server. Ansible …
Puppet was selected before I joined the team, had it been my choice I would have much rather went with Chef as it has the ability to do things that Puppet has not yet added to their system such a the ability to quickly query what host currently are allowing puppet to maintain …
I have not used any other Configuration Management System since cfengine back in about 2007 so I have little current input on alternatives to Puppet having never used them, though Chef seems to have gained some traction as has Ansible.
Puppet has a very wide user base with many organizations tht support it as well as conferences and events. Puppet DSL is based in Ruby while the server is now in Clojure providing ease of configuration with the power of scale. Puppet is a great entry point into the world of …
We were Puppet users. Red Hat Ansible Automation Platform made more sense to us because of the focus on Ansible content to support our AIX systems and RHEL systems. We have also seen that the learning curve for Red Hat Ansible Automation Platform is better than we experienced …
It was much simpler to deploy and use Red Hat Ansible Automation Platform in our enterprise environment. Red Hat has great training to get our users up to speed. YAML is easy to write (although watch out for spacing) and run playbooks. We can easily generate infrastructure …
All three of these competitors are agent based. I did not want an additional service that needed to run absolutely everywhere. I also did not want to maintain a load balanced cluster of master servers that grows in resource requirements as your infrastructure scales.
Ansible is much easier than Puppet, more enterprises are switching from Puppet to Ansible due to ease of use. Ansible has integration modules which allow you to transition from Puppet or Chef to Ansible. IT Automation space has a CAGR of 200%+ what are you doing to not get left …
Ansible has unique features in terms of server managing and configuring. It is easy to use and fits the Red Hat Linux well since they are closely related. Our servers are mostly Red Hat, so it makes sense to use Ansible. But we are still exploring which is the best.
Chef is something that was used previously by our head engineer and is quite similar to Ansible. They're both great configuration management tools. However, since Ansible is agent-less, we decided to switch for the convenience and quick-start nature of Ansible. Along with that …
Ansible is a great product, which we really love as it is compatible running along side and with other DevOps tool. The integration features allows other teams to participate in our shared objective. Ansible is easy to use as many programmers are familiar with Python and RHEL. …
In the time of integration, we chose Ansible instead of Puppet because it was simpler to use, based on Python and didn't require additional server environments to run. Of course, there are a lot of different alternatives like Chef or Salt Stack.
Ansible is sufficient for our purposes because our configurations are relatively simple. Chef and Puppet would work better for more complex configurations. Also, our applications are deployed using Docker which simplifies our configuration requirements. An organization with …
Ansible is much simpler to get up and running with than Chef, as it requires no infrastructure or agent process or any configuration on the target machine. All you need is SSH access! However, you lose the capabilities that Chef server offers such as data bags (centralized data …
I haven't used Puppet personally, but I believe Ansible is a robust solution which can serve many purposes. Puppet I'm sure is customizable in similar ways, I just don't have the experience to speak intelligently on the subject.
I have used Puppet, Chef during my career and Ansible seems to be the most efficient tool by far, in terms of its implementation, configuration and ease of use.
Chef is a fantastic tool for automating software deployments that aren't able to be containerized. It's more developer-oriented than its other competitors and thus allows you to do more with it. The Chef Infra Server software is rock-solid and has been extremely stable in our experience. I would definitely recommend its use if you're looking for an automation framework. And it also offers InSpec which is a very good tool for testing your infrastructure to ensure it deployed as intended.
Puppet is good enough to get the job done, you can use it to automate deployments and maintain files and configurations, if this is all you're looking for it's great. If you're looking for more control over your systems as a whole without having to write your own scripts or install multiple configuration management systems then Puppet is not what you're looking for.
It has helped save us so much time, as it was designed to automate mundane and repetitive tasks that we were using other tools to perform and that required so much manual intervention. It does not work very well within Windows environments, understandably, but I would love to see more integration. I want it to be sexy and attractive to more than just geeky sysadmins.
Debugging is easy, as it tells you exactly within your job where the job failed, even when jumping around several playbooks.
Ansible seems to integrate with everything, and the community is big enough that if you are unsure how to approach converting a process into a playbook, you can usually find something similar to what you are trying to do.
Security in AAP seems to be pretty straightforward. Easy to organize and identify who has what permissions or can only see the content based on the organization they belong to.
Chef could do a better job with integration with other DevOps tools. Our company relies on Jenkins and Ansible, which took some development and convincing for plug-ins to be created/available.
It would be nice if kitchen didn't only have a vagrant/virtual-box prerequisite. Our company one day stop allowing virtual-box to run without special privileges, and that caused a lot of issues for people trying to do kitchen tests.
Chef could use more practice materials for the advanced certification badges. There was not a lot of guidance in what to study or examples of certain topics.
The setup of Puppet is a nightmare compared to ansible. Anyone watching a youtube video can easily set up ansible with minimal IT knowledge. All one needs is the source IP addresses and we are good to go. Setting up Puppet is a more hands-on task and pushing the puppet agents to all the boxes is another issue. If the installation and setup were simplified like ansible that would attract a lot of people to this platform
The syntax of the code for Puppet is not as easy as ansible. Ansible simply follows a YAML format and it's like typing in normal English. Even complicated tasks can be written by just understanding YAML syntax. Perhaps Puppet needs to revisit the lanugage used and try to come up with a much simpler lanugage for writing code. This will make day-to-day usage easier.
YAML is hard for many to adopt. Moving to a system that is not as white space sensitive would likely increase uptake.
AAP and EDA should be more closely aligned. There are differences that can trip users of the integration up. An example would be the way that variables are used.
Event-driven Ansible output is not as informative as AAP.
Even is if it's a great tool, we are looking to renew our licence for our production servers only. The product is very expensive to use, so we might look for a cheaper solution for our non-production servers. One of the solution we are looking, is AWX, free, and similar to AAP. This is be perfect for our non-production servers.
The suite of tools is very powerful. The ability to create custom modules allows for unlimited potential for managing all aspects of a system. However, there is pretty significant learning curve with the toolset. It currently takes approx 3-4 months for new engineers to feel comfortable with our implementation
It loads quick enough for basically all our systems. Because we have this for local dev environments, speed isn't really a big issue here. Yes, depending on the system, sometimes it does take a relatively long time, but it's not an issue for me. One thing that is annoying is that if I want to make a small change to a cookbook and re-run the Chef client, I can't just make the change in the cache and run it. I have to do the whole process of updating the server.
Great in almost every way compared to any other configuration management software. The only thing I wish for is python3 support. Other than that, YAML is much improved compared to the Ruby of Chef. The agentless nature is incredibly convenient for managing systems quickly, and if a member of your term has no terminal experience whatsoever they can still use the UI.
Support for Chef is easily available for fee or through the open source community as most the issues you will face will have been addressed through the Chef developer community forums. The documentation for Chef is moderate to great and easily readable.
Puppet has top class support. You can simply mail them with their query and they will respond to your query in a timely manner. We do have enterprise license for puppet. Also there is a vibrant community for puppet out there. So even if you dont purchase a premium support option you can simply google your queries and get answers
There is a lot of good documentation that Ansible and Red Hat provide which should help get someone started with making Ansible useful. But once you get to more complicated scenarios, you will benefit from learning from others. I have not used Red Hat support for work with Ansible, but many of the online resources are helpful.
We considered the three leading competitors in the field: Chef, Puppet and Ansible. Ansible is a very strong competitor and has a nice degree of flexibility in that it does not require a client install. Instead the configuration is delivered by SSH which is very simple. Puppet seems like it has fallen off the pace of the competition and lacked the strong community offered by Chef. We chose Chef because of the strong support by the company and the dynamic and deep community support.
HPSA is a licensed product and incurs significant upfront investment costs due to COTS licensing. Puppet Data Center Automation has a significantly lower upfront investment and product documentation is more readily available. Chef is a very similar offering, however, at the time our decision was considered, the adoption of Chef vs. Puppet was significantly less in the community.
I haven't thought of any right now other than just doing our own home-brewed shell scripts. Command line scripts. And how does this compare? It's light years ahead, especially with the ability to share credentials without giving the person the actual credentials. You can delegate that within, I guess what used to be called Ansible Tower, which is now the Ansible Automation platform. It lets you share, I can give you the keys without you being able to see the keys. It's great
The entire professional services team was great to work with. The curriculum was tailored to our specific use cases. The group we worked with were very responsive, listened to our feedback, was very easy to schedule and accommodate. I cannot say enough good things about our professional services experience
Chef is a good tool for baselining servers. It will be a good ROI when there are huge number of servers. For less number of servers maintaining a master will be an over head.
One good ROI will be that the Operations Team also gets into agile and DevOps methodologies. Operational teams can start writing scripts/automations to keep their infra more stable and their application stack more reliable.
Implementation of Chef eliminates the manual mode of doing things and everyone aligns to automation mind set. It helps in change of culture.