Helpful Syntax

To be completely agnostic with regard to the many different target platforms, the Terraform developers have come up with their own declarative configuration language, also known as Terraform for short, which can be used natively as well as in a form converted to JSON.

At its core, the language comprises a small set of basic entry types. A block is a bracket that groups one or more resources and the parameters associated with them. Listing 1 shows a complete example of a block that references another resource (aws_network_interface). To turn the example into a complete, working example, you would need to create an additional aws_network_interface block, which in turn would need to reference at least the aws_vpc as well as aws_subnet resources.

resource "aws_instance" "foo" {
  ami           = "ami-005e54dee72cc1d00"
 # us-west-2
 instance_type = "t2.micro"
 network_interface {
 network_interface_id = aws_network_interface.foo.id
 device_index         = 0
 }
 credit_specification {
 cpu_credits = "unlimited"
 }
}

The resources in Terraform reference each other in a nested way, but the syntax never becomes so complex that it becomes unmanageable. The example shown here also makes it possible to understand the syntax of a Terraform block. A resource is always the type of resource to which the respective entry refers. Terraform uses its provider modules to identify resources (more on that subject later). The resource type to be called is backed up by an identifier, which needs be defined for each resource in Terraform and must be globally unique.

The Terraform language is not so complicated that you can't learn it relatively quickly and is one of HashiCorp's unique selling points, in addition to its versatility. These advantages immediately become apparent when you look at the second central component of Terraform: the modules.

Pooling Resources

What sounds complex is actually relatively simple. The example from Listing 1, for example, covers just a part of the definitions needed to launch a virtual instance on Amazon with a virtual network by Terraform. On the other hand, you need the resources for the network and, if so desired, for persistent storage. This is where modules in Terraform come into play.

Under the hood, modules combine various API calls in the target environments to make your life easier. To stick with the idiom of the previous description: When you call a module, Terraform derives a set of resource statements from it in the background, before proceeding to align the resources.

For a good example of this, you again need to enter the AWS world: The vpc module creates a virtual network in AWS and lets you create its subnets in simple notation instead of fiddling with resource statements. If you call the ec2-instance module after the VPC module in your projects, you can then directly reference the subnet created by the VPC. The two resources can also be linked.

Provider at the Core

This functionality begs the question: If modules only bundle resources, how do they know which ones to bundle? What is the origin of that part of Terraform that ultimately generates the code in Amazon Elastic Compute Cloud (EC2), Azure, and the like from the Terraform scripts? Herein come the providers: They mediate between Terraform on the one hand and the target platforms on the other.

Out of the box, Terraform already comes with a huge selection of providers. The AWS provider, which has already been mentioned several times, is certainly the king of the hill. That said, the providers for Azure or Google's GCP offer a similarly high level of functionality. You would be mistaken to assume that Terraform can only be used to manipulate resources in cloud environments, though. In the meantime, Terraform's abstraction capability is so massive that other tasks can also be implemented completely without reference to the cloud. If you use this type of provider, Terraform is more of an automation solution such as Puppet or Chef in some ways, with a complexity that can be compared with that of Ansible.

If you look at the list of providers [2] at Terraform, it quickly becomes clear that the HashiCorp is not holding back. Terraform maintains a public directory of all available providers in the form of the registry, a kind of public marketplace (Figure 3). In addition to the providers mentioned for public clouds, you will find providers for OpenStack, for Oracle's public cloud, and for a variety of Kubernetes distributions. Pods can then also be defined directly in Kubernetes by Terraform, or containers can be managed in a fully automated process across the nodes of a fleet manager.

Figure 3: HashiCorp operates a registry for providers that acts as a kind of public marketplace.

If you use content delivery networks (CDNs) such as Akamai or Cloudflare, you can also manipulate and control them with Terraform, as you can databases: With the use of different providers, you can execute actions directly in MongoDB or MariaDB, for example. Worth mentioning for fun: You can use a Terraform provider to order pizzas from the US pizza delivery service Domino's.