Automation is not just "nice to have" in the data center – it is an absolute requirement. The much-cited shortage of skilled employees alone is forcing companies to use automation to free up development resources by letting well-trained employees get on with the interesting work rather than keeping them busy with repetitive tasks.

Many admins today don't even bother fully automating their own bare metal, in large part because of the cloud, which seeks to help admins forget all their worries. Yet it is precisely the cloud that impressively shows that many problems don't disappear at all but simply mutate. However, automation in a cloud environment, called orchestration, has to work differently than on bare metal.

Orchestration originally arose as a special form of automation, wherein a template file describes how the virtual environment should appear and then feeds this request to a special service for evaluation (Figure 1). The orchestrator then draws on the other cloud services to create the required resources in a completely automatic and mutually coordinated way.

Figure 1: Automation in clouds is known as orchestration and is put into practice by services such as AWS CloudFormation. © LevelUp

Unfortunately each cloud technology has its own templates and syntax that are not exchangeable. Especially in hybrid setups with multiple public cloud approaches, you can very well be forced to do the same work multiple times. This is where Terraform comes in.

Technology Jungle

For years, HashiCorp's tool has touted itself as a powerful and environment-agnostic multicloud orchestrator with its own syntax and an abstraction layer for the major vendors' orchestration APIs. To be sure, Terraform also has its own commands for launching instances in Amazon Web Services (AWS), Azure, or Google Cloud Platform (GCP), so you still do not gain a generic machine resource. However, Terraform offers the huge advantage of only requiring you to learn one set of syntax rather than familiarizing yourself with a wide variety of services. Moreover, the entire infrastructure can be defined as a single continuous directory instead of messing around with custom solutions for Azure, AWS, and the like.

A few months ago, the developers released version 1.0 of Terraform, which they describe as a milestone in the project's history. Now is the perfect opportunity to put Terraform through its paces. How does the tool work, and does it deliver what the vendor promises in terms of cloud orchestration?

Editions

Terraform is open source software at its core, and the basic community version of the software, displayed predominantly on their website [1], forms the basis of the other versions offered by the HashiCorp, including the cloud variant hosted by HashiCorp for cloud users and an Enterprise edition.

The latter version, of course, is aimed at companies that need an on-premises instance of the entire Terraform environment and do not want to see it hosted in a cloud – even though the product the admin gets with Terraform Enterprise is ultimately an on-premises installation of Terraform Cloud. Accordingly, the solutions also share a feature set: Single sign-on (SSO) via Security Assertion Markup Language (SAML) is available in Terraform Cloud and Enterprise, as is the option to store a completely custom layout for networks in the cloud.

Multiclient capability for multiclient software-as-a-service (SaaS) offerings is missing from the classic Terraform, as is extended logging for auditing purposes. The practical GUI for various tasks in Terraform Enterprise is more or less the cherry on top (Figure 2). It is doubtful whether so many pretty accessories are necessary in many environments. Terraform is obviously looking to compete with products such as Ansible Tower or Puppet Enterprise with its cloud and enterprise offerings.

Figure 2: The Workspaces view, which can be used to centralize management of various projects, is reserved for Terraform cloud variants and the Enterprise on-premises version. © HashiCorp

However, the vendor's flowery descriptions on the website cannot hide the fact that Terraform itself (i.e., the core of the solution) has a great deal going for it in the form of open source software and will be all people need in many environments. What can admins expect if they stick with the open source version, and what can you actually do with the product?

Clear-Cut Architecture

When you look at the schematic of the Terraform components, you will notice that the solution is pleasingly simple. If you look at the orchestrators of the major clouds in comparison, you almost always have to deal with various APIs, different daemons, and additional components that all have to be gathered under a single roof.

Not so with Terraform and the Terraform Core, which is equivalent to the terraform command-line utility. Unlike competing solutions, Terraform does completely without its own APIs or daemons that store arbitrary states. Terraform is not completely stateless, though: Terraform takes care of managing its states itself. Files with a .tf file extension let you describe the state that resources in the various clouds need to have. These state files can be stored either locally or in a remote store (e.g., on Amazon's S3). The remote option has the advantage that Terraform can fetch the target state from the network at any time, which means that the program can be called from any host.