Tried and Trusted

IT without automation is simply impossible to imagine today. One of the many mantras of strict advocates of automation is: "If it's not automated it doesn't exist." In view of a continuing shortage of skilled workers, companies have virtually no choice – if you task expensive personnel with performing the same banal maintenance chores time and time again, you will simply be unable to achieve the high degree of innovation required in present day business.

It comes as no surprise that many large and small providers want a piece of the pie. One automation topic has seen much attention in recent years: workloads in the cloud. A separate sub-genre of automation has even emerged – orchestration – which, although it takes automation up several levels, is ultimately still automation at the end of the day.

Special Cloud Tools Often Not Needed

The range of orchestrators and automators for managing workloads in clouds is as diverse as the cloud candidates themselves. Specific solutions exist for each of the major public cloud providers, and private clouds have additional tools that are based on OpenStack, for example. Admins sometimes face a dilemma: Which solution is the best for my application? Is it worth spending large sums of money on additional software?

Often enough, the answers to these questions are an unequivocal "No." If a company already uses an automation tool such as Ansible, it will likely also be able to handle the cloud-based tasks. Often enough, though, administrators who work with these tools on a daily basis are not even aware of the fact.

This article pursues several goals. I want to sharpen the admin's senses that many automators can handle cloud tasks well out of the box, and I want to provide an overview of the cloud capabilities of the most important established applications: Puppet, Chef, Ansible, and Salt. This endeavor, then, translates into in a market overview that will hopefully benefit you as a guide to automation in the cloud.

To begin, however, a small clarification is necessary: Automation providers and cloud providers alike have long taken note that admins often lose their way in the flood of potential approaches. In line with this, many manufacturers have put together no-work dream packages in collaboration with the cloud providers. Automation is then available as a software-as-a-service (SaaS) offering with just a few mouse clicks. The system administrator is spared what can be a complex setup process (e.g., rolling out the Puppet master in the case of Puppet). Where such solutions exist, I will point them out, but my focus is clearly on the capabilities of the individual automators for starting and managing cloud workloads.

All of the tools I look at here are open source software and available for free from their providers. I will examine how well each automation solution handles the Amazon Web Services (AWS), Azure, and Google Cloud Platform (GCP) public clouds. In terms of private cloud support, I will also be taking a look at the OpenStack capabilities of the applications.

Puppet: Constantly Improving

Puppet enjoys an excellent reputation among admins, partly because the software has improved continuously. Although Puppet was too carefree with available resources a few years ago, the developers now have a handle on this problem. The Puppet architecture has hardly changed in recent years. The developers still recommend a master-agent approach, in which a central instance computes most of the system configuration to be applied to the target systems and forwards it to the agents.

In the cloud context, this sounds a bit strange at first, because the target systems are not actually systems but instead, say, the AWS APIs designated to create or delete resources by making appropriate calls. In fact, cloud integration in Puppet is generally slightly more complex because Puppet itself bundles the topic of cloud with a number of commercial offerings, most of which are clearly geared toward AWS.

Puppet for AWS

For example, Puppet Enterprise is available as a click-and-collect application on the AWS Marketplace, including billing with an AWS account. Puppet Enterprise is the manufacturer's big automation solution with a GUI and all the trimmings, which in the AWS-specific version is of course also customized for the AWS APIs, from which it maintains its inventory of systems to be managed. It goes without saying that it is also possible to provision AWS instances with a Puppet Enterprise instance running in AWS.

If you don't need something quite so all-encompassing, OpsWorks is a better choice. It can also be launched very quickly from the AWS marketplace and has a far leaner feature set than Puppet Enterprise. Essentially, it is a Puppet master automatically managed by AWS, with various features available at the admin's behest. OpsWorks saves setup and maintenance time, which is then billed by Amazon and Puppet.

One thing that is striking about Puppet and AWS is that the whole field is so full of commercial offerings that a DIY use case is not easy to implement. What I mean is an approach in which the admin builds a minimal setup from Puppet free/libre open source software (FL/OSS) components, with which it then controls the AWS resources. Undoubtedly, an approach like this would offer the advantage of coming without the complexity of OpsWorks or Puppet Enterprise, but the road can be rocky, not least because Puppet almost seems to hide the required components. For example, some AWS modules in Puppet Forge can be easily integrated into a local Puppet instance, even if the last version is just a few days old, and you can use these modules to control resources in AWS.