Module Design: Achieving the Right Level of Abstraction

Module-related questions account for 25% of code organization issues, with the primary challenge being determining appropriate boundaries.

The Problem

# Overly complex monolithic module
module "application" {
  source = "./modules/application"
  
  # Dozens of variables for every possible configuration
  environment         = var.environment
  instance_count      = var.instance_count
  instance_type       = var.instance_type
  database_engine     = var.database_engine
  database_size       = var.database_size
  load_balancer_type  = var.load_balancer_type
  # ... many more variables
}

The Solution

# Composable, focused modules
module "database" {
  source = "./modules/database"
  
  environment     = var.environment
  engine          = var.database_engine
  size            = var.database_size
}

module "compute" {
  source = "./modules/compute"
  
  environment    = var.environment
  instance_count = var.instance_count
  instance_type  = var.instance_type
}

module "load_balancer" {
  source = "./modules/load_balancer"
  
  environment = var.environment
  type        = var.load_balancer_type
  targets     = module.compute.instance_ids
}

Smaller, purpose-specific modules are easier to understand and maintain. Scalr's registry makes it simple to discover, publish, and version these modules across your organization.