Lego was a major part of my childhood. I could spend endless hours digging through plastic bins of deconstructed lego pieces searching for an exact piece to complete my masterpiece. I can still hear the audibles lego makes when digging through piles of them (Lego enthusiasts can relate). There was something satisfactory, yet educational, about assembling a Lego from start to finish; you understood the constructs of the plastic sculpture.
Lego pieces can be assembled and connected in a myriad of ways to construct objects that resemble real life machinery, buildings, and scenes. Lego cleverly packages the pieces to build something extraordinary. Each manufactured box set, however, allow us to build something specific. The box contains instructions and the pieces necessary which allows you to build a Lego model with intent.
Lego Installations
It doesn't stop there. A single Lego set, a police station for example, can be joined with other sets to build larger and more complex scenarios like cities. Of course everything can be built from the ground up using loose pieces. However, the box sets allow you to you assemble models as the designer intended. Lego sets allow for requirements, constraints, and limitations that ensure a proper build. In reference to infrastructure, what can we learn from Lego when building infrastructure?
Cloud Providers
We are surrounded by public cloud offerings (AWS, Azure, GCP, etc) which provide the basic pieces. Think of these as the Lego store where you can dig into bins of loose Legos.
These public cloud providers offer hosted services EKS, AKS, GKE, etc. These services are the individual Lego pieces for hosted applications.
Engineering Teams
Engineers assemble infrastructure by strategically putting together services (the Lego pieces) with the goal of deploying and running applications. This could range from monoliths to micro-services, or stacks containing all the necessary services aggregated together required to deploy applications. Think of engineers as designing the Lego sets (aggregating pieces that make up a Lego police station). A Terraform resource can be correlated with a Lego set.
resource "azurerm_public_ip" "vm" {
count = var.nb_public_ip
name = "${var.vm_hostname}-pip-${count.index}"
resource_group_name = data.azurerm_resource_group.vm.name
location = coalesce(var.location, data.azurerm_resource_group.vm.location)
allocation_method = var.allocation_method
sku = var.public_ip_sku
domain_name_label = element(var.public_ip_dns, count.index)
tags = var.tags
}How do Terraform modules relate with Legos? Major cities often times have unique differences, but at their core are quite similar most of the time. An important consideration is placement like where things are located on a map.
Going back to our previous example, where will the Lego police station be placed in reference to the city? We can build many different cities using the same Lego sets by simply changing where they are placed.
module "azure_vms" {
source = "git@ssh.dev.azure.com:v3/project/modules/terraform-azurerm-compute?ref=master"
resource_group_name = local.rg_name
location = "eastus2"
avs_name = module.avs_naming.availability_set.name_unique
name_index_offset = local.is_name_overridden ? 0 : data.external.vm_index_offset.result["index"]
vm_hostname = lower(local.vm_name)
is_name_overridden = local.is_name_overridden
nb_public_ip = 0
nb_instances = var.vm_count
admin_password = random_string.password.result
vm_os_id = data.azurerm_shared_image_version.this.id
vm_os_simple = ""
is_windows_image = var.is_windows_image == true ? true : false
vnet_subnet_id = data.azurerm_subnet.this.id
extra_disks = local.extra_disks
nb_data_disk = 1
data_disk_size_gb = 16
data_sa_type = "Standard_LRS"
storage_account_type = var.storage_account_type
boot_diagnostics = false
delete_os_disk_on_termination = true
enable_ssh_key = false
vm_size = local.instances[var.instance_type]["cloud_size"]
enable_zones = var.enable_zones
custom_data = var.is_windows_image == false ? base64encode(data.template_file.user_data.rendered) : null
tags = module.tags.map
}For each environment, there‘s a terraform file defining which modules to include, files containing definitions of variables and outputs, alongside the actual configuration data to be used. These are aggregating loads of Terraform resource attributes (Lego sets) to make up our overall infrastructure (Lego city). In some situations the components of the city are determined by the user. Does the city have a hospital? Is there more than one hospital? The placement of these components are often times ordered and specific. Other times they are completely decided by the user's request. This may be from the result of pipeline inputs or a user interface feeding the automation that is then orchestrating the lexigraphical order of the infrastructure deployment.
When a user requests infrastructure, how the Terraform resources are created and the Terraform module composition is irrelevant from their perspective. What matters is that the underlying components build the infrastructure resulting in a correct configuration. The user requested a Lego city, it's up to the engineers to ensure the city is adequately designed and ordered properly to deliver the right specifications as requested.
The good news is that this is all possible with Terraform. The permutations are limitless meaning that you can provide customizations to meet your exact needs. Here at Mentat, we can help you design your Terraform resources to then build a well-crafted Terraform module. From there, you have a reusable blueprint that can be used reptitively to accomplish your business infrastructure objectives efficiently and accurately.