Terraform is great. It has sort of become the de facto coding language for anyone looking to implement and adopt a multi cloud strategy. Our team has been recommending the adoption of terraform to anyone we can. However, like any major technologies out there, terraform has grown so big that some myths have started floating around about it. We occasionally see some of our clients talking about these and we obviously clarify the reality vs their expectations. We will discuss one such case here today.

Terraform is known as a single language for all cloud environments. Before terraform, we had cloud automation languages but mostly they were different languages for different clouds. I say “mostly” because I have seen many predecessors of terraform which had equally if not more promising claims about being single language for all clouds before fading away from competitive horizon. We had cloudify – a very promising opensource cloud automation / orchestration language which was YAML based and even had great initial success in telecom industry. We had cliqr which got later acquired by Cisco. Cliqr was very promising. So was Calm.io which got acquired by Nutanix. Terraform dominated these competitions to become what it has become today. And it did so by the sheer power of opensource rapid development of features combined with one of the best documentations for any product out there.

Now, terraform’s biggest competitors were obviously the native orchestration coding languages of each cloud such as cloudformation of AWS, ARM of Azure, Heat Templates of Openstack etc. And one major drawback of terraform against them always has been and always will be the fact that these native languages will always be one step ahead of terraform in supporting the latest cloud features since they are indeed the “native” coding languages of the cloud service provider.  But terraform being a coding language from a third party company i.e. Hashicorp, lacks the immediate support for some bleeding edge new features and typically takes a lead time for developing compatibility with the newly released features. It has never stopped terraform’s fanbase to love the product more. In fact one of the main strong point about terraform is the community’s agility to adopt changes in cloud provider API (Application Programming Interface).

Terraform is adopted as a must by people who intend to leverage a multicloud strategy. A multicloud strategy is where you decide to not to put all your eggs (application services) in one basket (one cloud) but rather you prepare a strategy of using multiple cloud service providers for various use cases better served by those clouds. For example, you may take some oracle services from Oracle cloud, some kubernetes services from Google, some .NET development integrations with Azure and generally use AWS. Or may be you leverage some machine learning and AI stuff from IBM. Some people and some organizations do plan like that. And while such plans are not always great, a real case for using the best service from the best in class provider can be made. For such cases, or for cases where multi cloud environments are used as DC-DR strategy, terraform makes a lot of sense. It has significant benefit for users of multiple cloud environments. Go to any terraform consultant and he/she will give you a long list of benefits to show how you can make your multi cloud operations so much better by adopting terraform.

However, while over enthusiastically listing the benefits of terraform, some consultants prepare slide decks and documents that glosses over a factual difference between portrayal of benefit vs reality of terraform. It has to do with calling terraform as the single coding language for all clouds. I am sure, this is the most well known argument and possibly the first one you might have also heard about terraform. It is true, but may be not in the way you are made to understand by those over enthusiastic presentations.

Terraform indeed is one coding language for all clouds supported by terraform. However, that does not mean that the codes need to be written once and the same code can be used across clouds. Terraform as a language may have the syntax for all clouds, but the code written for one cloud is absolutely incompatible with another cloud. But that sounds just like the case of native cloud orchestration languages, isn’t it. For example, what was the argument in favor of terraform and against of the likes of AWS CFT, Azure ARM, Openstack HOT? It was that the AWS CFT code only works in AWS cloud and if you decide to use Azure then you have to write the same automation again from scratch for the Azure cloud using Azure ARM language and if you decide to use Openstack, then the entire automation has to be written again using the Heat Orchestration Template language. Instead of that terraform is this One Single Language for All Clouds. Like that one ring to rule them all. But if now I say, terraform code written for AWS automation does not work as it is at all on any other cloud and for doing the same automation let’s say on Azure, you have to write the whole automation again in the terraform format compatible to Azure, then you may feel disappointed compared to your expectation of using same terraform code across clouds as some consultant might have made you believe.

The reality is that for almost all cases, AWS terraform code is incompatible to Azure and vise versa. And the same is true for all clouds and their corresponding coding construct of terraform. If you have made great automations in AWS using terraform and then tomorrow you decide to move/migrate away from AWS to Azure, then all those codes are mostly going to be wasted and you have to rewrite all your automation codes again for Azure. There’s no way you can reuse the terraform code written for one cloud directly into the other cloud.

Now before we move further, it would be wise to understand the multi cloud compatibility mechanism of terraform – the internal organs of the terraform that makes it the magical coding language which it is indeed.

Terraform uses a concept of providers, plugins, resources, datasources etc. I have seen people to understand this part by comparing terraform to an operating system. Think of your document scanner hardware. You may buy it from HP, Canon, Brother etc. They all have their own hardware that can be used by installing the company provided driver software into your operating system. Once you install the driver in your operating system then the same operating system can be used scanning documents from all these different printers. Think of the “provider” components of terraform as the driver software of terraform to connect to different clouds. The “plugin software” is a package that terraform downloads as a software to work with the provider. The same “coding language” then can be used across multiple clouds. Just like the same scanning activity can be carried out by the operating system across all scanners once drivers are installed. However, if you come to think of it, every scanner not only comes with drivers but they also come with scanning software. And although you might be doing the same things for all scanners, these software interfaces are specific to a scanner company. Like HP’s scanner application interface will be very different from the Canon version of the similar software – although both will be used to achieve the same outcome. In terraform, we have resources that help us launch/modify/destroy services on a cloud. These services are similar across clouds but depending on cloud we have cloud specific “resource types” in terraform to deal with. To launch a VM, terraform for AWS uses a resource type named as “aws_instance” and for the same purpose, terraform for Azure uses a resource type named as “azurerm_linux_virtual_machine”. The end outcome is same (launching a VM on a cloud) but the resource code is completely different with completely different parameters applicable for each resource type.

So where does terraform help us as the promised “common language” across clouds? Now in our scanner example, think of the interfaces of those scanner device company specific scanning software interfaces. As long as you know that you are using Windows operating system, you know for sure that each of these software will have a nice intuitive GUI for you to work with. And if you understand how Windows GUI works, you will somehow figure out how the scanner interface works, no matter how the HP one may be different from the Canon one. Unlike the case would have been for Linux (only the cli version case that is). In case of linux commands, the scanners would actually require a whole different way of working and would be having their independent cli commands that are completely different from each other. No matter how much expert you are for one scanner company’s cli, you can never guess the commands for the other company’s cli. They will not have much in common. This is where the Windows GUI although different in terms of absolute UI elements, does help you to intuitively use the Windows GUI scanning applications intuitively irrespective of the scanner company – because you understand the Generic GUI language of Windows OS. Terraform is like that. You know the language and if you are expert on on writing terraform codes for one cloud, you can easily grasp the language changes required for another cloud. But they are never going to work as it is across clouds. You have to rewrite the code.

So how different are they?

Lets take a look at the code to launch a single VM in AWS vs in Azure using the same terraform language.
Code for Launching a VM on AWS using Terraform:

provider "aws" {
region = "us-west-2"
}

resource "aws_instance" "web_server" {
ami = "ami-061392db613a6357b"
instance_type = "t2.small"
tags {
Name = "my_server"
}
}

Well that one is quick and short.
However, in Azure, you need to write a bit more code.
Code for Launching a VM on Azure using Terraform:

provider "azurerm" {
  features {}
}
resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "West Europe"
}

resource "azurerm_virtual_network" "example" {
  name                = "example-network"
  address_space       = ["10.0.0.0/16"]
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
}

resource "azurerm_subnet" "example" {
  name                 = "internal"
  resource_group_name  = azurerm_resource_group.example.name
  virtual_network_name = azurerm_virtual_network.example.name
  address_prefix       = "10.0.2.0/24"
}

resource "azurerm_network_interface" "example" {
  name                = "example-nic"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name

  ip_configuration {
    name                          = "internal"
    subnet_id                     = azurerm_subnet.example.id
    private_ip_address_allocation = "Dynamic"
  }
}

resource "azurerm_linux_virtual_machine" "example" {
  name                = "example-machine"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
  size                = "Standard_F2"
  admin_username      = "adminuser"
  network_interface_ids = [
    azurerm_network_interface.example.id,
  ]

  admin_ssh_key {
    username   = "adminuser"
    public_key = file("~/.ssh/id_rsa.pub")
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "UbuntuServer"
    sku       = "16.04-LTS"
    version   = "latest"
  }
}

Looks quite different. Isn’t it? So terraform codes are indeed quite different between different clouds. But there is one major benefit if you carefully look into the examples shown here.

The benefit is in reduction of effort required for the team to handle codes for different clouds. Since they know the language, they have to just learn the way new cloud and the new resource types work. Syntax, Logical structures etc. remains same. That is where terraform excels and it is important to understand the difference between that and the misunderstanding of terraform being the single code for all clouds.