Chef and Ansible

Chef and Ansible both help DevOps teams automate management of applications and infrastructure. However they have important differences you should understand when evaluating which one is right for you.

Learn more about automation in our exclusive whitepaper, “Continuous Automation for the Continuous Enterprise.”

Download Whitepaper

Compliance Automation

In addition to automating infrastructure with configuration management, Chef Automate includes support for automating compliance assurance. Ansible does not have compliance automation.

Applying system configuration is a vital concern when first provisioning applications and infrastructure. Ensuring those components don’t expose your organization to additional risk is a vital concern during the remaining lifecycle of your infrastructure and applications.

Read Compliance Automation: Bridging the Gap Between Development and Information Security

Scalable performance

Ansible provides an agentless execution model that makes it easy to get started without the need to manage additional software. Ansible compiles specified playbooks which it then sends to each node via SSH for execution. This direct execution model means the more nodes you manage, the more performance degrades. At small scale, the performance impact is manageable and typically unnoticeable. In distributed production environments, that linear performance leads to exponential failures once system performance thresholds are reached.

Chef relies on installing an agent (the “chef-client” binary) on each managed node. Each chef-client takes on the brunt of managing any performance impacting operations locally. By distributing this load across every machine in your fleet, Chef makes it easy to manage tens of thousands of servers without suffering from performance degradation.

Support for heterogenous environments

Ansible is a part of the RedHat technology ecosystem and it provides integrations with many RedHat solutions. Ansible relies on an existing installation of the Python programming language, which is commonly found across many Linux operating system distributions. Ansible is not designed to work with Windows systems using native technology.

Chef is vendor neutral when it comes to operating system choices. The chef-client agent is bundled into self-contained binaries that install all necessary dependencies in several OS flavors to support the most heterogeneous system environments. Chef recognizes that not all systems are created equal and it provides OS specific resources designed to leverage native technologies for a smooth operational experience.

Chef makes it easy to adopt continuous automation, no matter what your current technology stack looks like, or what you’d like it to be in the future. Our deep and ongoing partnerships with Microsoft, Amazon, VMware, Google and others help ensure that our platform works with whatever you want to manage.

Learn more about Chef Automate

Managing complexity

Ansible’s focus on simplicity makes it a good match for organizations with limited skill sets and a small infrastructure footprint. Ansible abstracts configuration into YAML modules called ‘playbooks’.

Playbooks offer a quick start, but they are inherently inflexible language. Any non-standard configurations or run complex change requires awkward workarounds. 

Chef has a domain specific language (DSL) that provides an easy to approach interface for managing basic configuration tasks.

For complex scenarios, users can leverage the full power of the Ruby programming language to model appropriate solutions.

Several established patterns for creating custom solutions exist and many are already available through Chef’s vibrant open-source development community.

You don’t need to know Ruby to use Chef, but when facing uncommon edge case scenarios it’s easy to use just enough Ruby to work your way through the most complicated tasks.

Executing remote jobs

Ansible’s agentless push-mode using a ZeroMQ implementation at the transport layer means quick deployment and low performance overhead when triggering ad-hoc jobs from a developer workstation or a central resource like the Ansible tower. However, the push model is not as flexible or powerful as using pull-based agents like chef-client.

Chef typically recommends running pull-based jobs via chef-client. However, Chef also provides a ZeroMQ-based push agent via its “push-jobs” add-on package. Chef builds its products to provide several implementation options for users so that they can model the appropriate solution to suit their environmental needs.