Terraform is a new tool to build, change and version infrastructure, such as VMs, network switches or containers. It comes from the creators of Vagrant, the popular tool for managing development environments.
Terraform's main selling point is its ability to combine and compose different service providers resources in a declarative and agnostic way. Amazon Web Services (AWS), DigitalOcean or Cloudflare are examples of service providers.
Terraform uses a declarative language to describe resources' configurations. A resource can be many things, such as: an AWS EC2 instance; a Heroku App or a Cloudflare record. Since Terraform is agnostic to service providers, there is the concept of providers. Providers translate Terraform configurations to low-level API interactions with the service providers.
Terraform works at a lower level than configuration management tools like Puppet or Chef. These tools work on existing resources, while Terraform builds those nodes. Using Terraforms's parlance, configuration management tools are provisioners, hence responsible for initializing a resource.
The resource lifecycle ensures that any change is safe and explicit by generating a change plan. Before applying the plan to change the infrastructure, the user has the opportunity to validate it.
Hashicorp decided to create a new configuration syntax, with the express aim of making the configurations as readable as possible. An alternate JSON-based syntax is also provided. There are several configuration examples in the documentation. The basic structure looks like this:
resource "digitalocean_droplet" "web" {
name = "tf-web"
size = "512mb"
image = "centos-5-8-x32"
region = "sfo1"
}
This block declares a resource of type "digitalocean_droplet" named "web". Everything inside the brackets is key-value configurations for the resource.
Since Terraform might be seen as overlapping with several classes of tools, there is a section on the tool's documentation that compares it with other software.
InfoQ talked with Mitchell Hashimoto, Hashicorp's founder and Vagrant creator, to learn more about this new tool.
InfoQ: Terraform uses a custom configuration syntax, justified by the need to be as readable as possible. Do you think that the new syntax justifies the learning cost? Why do you consider that languages like YAML aren't enough?
Mitchell: Creating our own configuration language was not a decision we made lightly.
Terraform is our 5th tool, and the 5th one that needs to be configured in some way. We've transitioned from Ruby (Vagrant) to JSON (Packer, Consul), and we've learned a lot along the way. The general thing we learned is that people want a human-readable and modifiable language to configure things, and yet with our tools they also want to be able to configure with a machine since we try to build tools that can be unix-friendly.
JSON is a decent balance, and has worked okay. The main downsides is that there are no comments and the format is pretty verbose for complex structures for a human.
I've personally never been a fan of YAML. I've tried reading the spec once and it seemed to simply do too much for my liking, and I've found that beginners never quite understand the structure they're creating.
As a result, we decided to build our own configuration language. We decided to take a different approach: human-readable and editable primary format, but JSON as the interoperability layer. Time will tell how this works, but so far we've had no complaints.
InfoQ: You choose to use explicit dependencies declarations for resources. Since the debate on explicit vs implicit declarations is a hot one, can you share your view on this?
Mitchell: Actually, Terraform dependencies are all implicit, with optional explicit dependencies.
The dependencies are inferred based on referencing variables in other resources. If you aren't referencing an attribute of another resource, there likely isn't a dependency, and Terraform assumes as much. However, you can use the
depends_onparameter for explicit dependencies if you want.
InfoQ: Hashicorp has already released five different products. What is the vision that has been guiding you in building these products? How do your products complement each other in that vision?
Mitchell: I'm glad you asked this. Many people ask if we're just solving random problems, or if there is a grand vision. And the reality is that there really is a grand vision behind all of our tools.
The guiding vision is really to make the entire dev and ops lifecycle an easier, more scalable process. Vagrant makes development easier, Packer makes base software easier, Serf/Consul make service discovery and configuration easier, and now Terraform improves provisioning the resources to run software. And all of our tools are designed to work with any technology choices underneath: physical machines, virtual machines, containers, any language, etc.
There are more products in develop and on the way. We work on multiple new products in parallel these days.
InfoQ: There has been some discussion about how all the new tools around ALM and DevOps are starting to become detrimental to the typical developer. What is your take on this discussion?
Mitchell: We're building tools to solve technical problems. We have our own vision of how workflow should exist within an organization but we haven't really started prescribing that yet.
I do admit that there is an explosion of DevOps tools that make for a confusing ecosystem. I think that the expansion is necessary before a contraction and simplification.