Compare Google Cloud Deployment Manager vs. Terraform on GCP

Google Cloud Deployment Manager

Google Cloud Deployment Manager is GCP's native infrastructure-as-code tool. IT teams use it to automatically create and manage Google Cloud resources. This tool provisions your resources in a systematic fashion that can easily scale with demand.

To deploy resources, Deployment Manager reads configuration from a YAML file. If you are familiar with tools such as Ansible and Kubernetes, you should be comfortable with YAML syntax. Below is a snippet of a YAML template that will create a virtual machine in GCP. To start, define the resource and specify the name and type.

resources:
- name: my-first-vm
  type: compute.v1.instance
  properties:
    zone: us-east1-d
    machineType: https://www.googleapis.com/compute/v1/projects/random-test-01/zones/us-east1-d/machineTypes/f1-micro
    disks:
    - deviceName: boot
      type: PERSISTENT
  ……… 

Modularize the template further by using Jinja or Python. As you can see above, the machine type is hardcoded, based on the zone the VM is being deployed to. This isn't ideal because it requires you to write separate templates for each zone you plan to use.

By using Python and Jinja, you no longer have to hardcode any of your resources. You can set the name of a resource to {{ vm_name }} and Jinja will determine the name programmatically, based on your definitions.

For example, if you want the resource names to indicate whether a resource is in the production or development group, you can do this with environment variables and, depending on the environment variable that is instantiated, you can build the name from it.

Terraform on GCP

Terraform is one of the premier infrastructure-as-code tools because it can provision resources from various vendors. Terraform is not restricted to a single cloud provider; you can easily switch from provisioning resources in GCP to AWS or Azure. It also supports on-premises environments such as VMware ESXi.

To define resources, Terraform uses a structured language called HashiCorp Configuration Language (HCL). HCL is considered its own programming language because it supports conditional logic and loops. These properties remove the need to use external configuration or a separate programming language such as Jinja and Python.

As you can see below, HCL is similar to JSON syntactically. Terraform has a higher learning curve compared to Deployment Manager due to its use of HCL but, with this language, you have the ability to use programming logic like using variables.

terraform {
   required_version      = ">= 0.12"
}

provider "google" {
  region      = var.region
  project     = var.project_name
  credentials = file(var.credentials_file_path)
}

resource "google_compute_http_health_check" "default" {
  name                = "tf-www-basic-check"
  request_path        = "/"
  check_interval_sec  = 1
  healthy_threshold   = 1
  unhealthy_threshold = 10
  timeout_sec         = 1
}
  ……

Google Cloud Deployment Manager vs. Terraform

So which infrastructure-as-code tool is right for your Google Cloud deployments? The choice ultimately varies based on your workload.

If you're only deploying workloads to GCP, Deployment Manager should meet all of your deployment needs. And because it's a built-in Google Cloud tool, it's also easier to use from an authentication perspective. On the other hand, Terraform is a better option when deploying to multiple cloud providers or vendors.

Terraform has built in programming logic within HCL, unlike YAML -- which needs Jinja and Python to extend its limitations. Keep in mind Terraform technically still doesn't have version 1 out yet. The current version of Terraform at time of publication is 0.13.4. Expect changes to occur until version 1 is released.

The tools also handle resource states differently. In GCP, Deployment Manager creates a manifest file that stores details about the resources deployed. This file cannot be edited by the user and is stored within GCP. Terraform has a similar feature called states that provides a glimpse into what resources are currently deployed. Terraform creates a state file during the deployment stage.

Unlike Deployment Manager, Terraform state files are not stored in the cloud by default; states can also be local on a developer's machine. However, this can be problematic when working in a team. If multiple engineers are editing the configuration files, it can cause the states to drift from one engineer to another.

To mitigate this issue, Terraform offers remote state locations. Remote state files work as a central location for Terraform to reconcile a deployment's configuration and the state of the currently deployed infrastructure. Terraform writes remote state to a remote data store that team members can share. Remote state stores include Amazon S3, Azure Blob Storage and Google Cloud Storage.