Chef: Suitable for All Clouds

As with Puppet, anyone planning and implementing their automation in a green field will first have to deal with the Chef infrastructure. Chef itself distributes a commercial product named Automate, which comprises several components, including a GUI (Figure 1). Under the hood, though, Chef Automate is the normal Chef, which you can use without the other Chef components. That said, if you use Chef in this way, you are missing out on a large number of features.

Figure 1: Chef comes with a wrapper application named Automate; it includes a GUI which is needed with AWS.

The Chef InSpec tool automatically checks physical and virtual environments for certain compliance factors. Just as the manufacturer offers Chef community modules for controlling AWS, Azure, and GCP resources, resources in these clouds can also be checked for compliance with InSpec. The InSpec AWS resource pack, inspec-aws, undoubtedly offers the greatest range of functions, but basic implementations are also available for Azure and GCP. In Chef's case, not only the software itself is cloud-friendly, but also its pretty accessories.

All told, the control Chef gives you over cloud resources is very satisfactory. In any case, anyone who is already using Chef will want to evaluate their options for letting Chef control their cloud workloads, as well, rather than opting for yet another third-party product.

Easier with Ansible

In the circus of commercial automators, Ansible now occupies something of a back-to-the-roots role. Of course, this is no coincidence, because Ansible was created a few years ago out of the motivation to bring a lightweight alternative to Puppet and Chef into the world. At the time, Puppet and Chef already had huge feature sets, but anyone who had not yet dealt with automation often found it difficult to get started with one of the two applications. In addition to automation itself, Chef and Puppet allow access to separate scripting languages, which are similar to common programming languages in both cases, although there are some significant differences in the details.

Ansible makes life far easier for newcomers to automation. Even on a freshly installed Linux system, it only takes a few minutes to call Ansible such that it actually performs configuration steps on other systems and requires little more than the Ansible program itself, plus an inventory of the target systems and some instructions on what you want Ansible to do on the target systems (the "playbook").

The advantage Ansible has here is its reliance internally on YAML, and the structure of the files containing the content tasks is basically that of a shell script. You define the commands in your Ansible roles and playbooks one by one, assisted, as with other tools, by the Jinja template engine, which facilitates handling the configuration files.

Good Team: AWS and Ansible

The AWS modules for controlling AWS resources with Ansible come from developers in the open source scene. However, this does not detract from their quality. Besides two plugins that can be used to create an inventory from a list of existing Elastic Compute Cloud (EC2) instances and Simple Storage Service (S3) buckets, various Ansible modules also manipulate resources. Creating a bucket in S3 is just as easy as starting or deleting a virtual compute instance.

Ansible also has a link to AWS CloudFormation, Amazon's orchestrator, in its modules, so you use the automator to control the orchestrator in this case. Strictly speaking, this setup is redundant, but if you don't want to do without CloudFormation's feature set yet and are not willing to learn its syntax, you will probably be quite happy with the arrangement.