cloudless
by skunxicat
philosophy ecosystem infrastructure

Composable Infrastructure

The Lego Principle

Infrastructure should be like Lego blocks. Each piece does one thing well. Combine them to build exactly what you need.

The Anti-Pattern

Monolithic frameworks that give you everything but let you change nothing:

  • Serverless Framework with 200+ plugins
  • CDK constructs that hide too much
  • Platform-as-a-Service that locks you in

Our Approach

Composable modules that solve single problems:

# Website infrastructure
module "website" {
  source = "git::https://github.com/ql4b/terraform-aws-website.git"
  fqdn = "example.com"
  context = module.label.context
}

# API infrastructure  
module "api" {
  source = "git::https://github.com/ql4b/terraform-aws-rest-api.git"
  context = module.label.context
}

# Custom runtime support
module "runtime" {
  source = "git::https://github.com/ql4b/terraform-aws-lambda-runtime.git"
  context = module.label.context
}

Module Design Principles

  • Single Responsibility: Each module solves one problem perfectly
  • Minimal Interface: Expose only what users need
  • Maximum Flexibility: Don’t make assumptions about usage
  • Clear Boundaries: Explicit inputs and outputs
  • No Hidden Dependencies: Everything is declared

The Composition Strategy

Foundation Layer: cloudless-infra

  • Consistent labeling via CloudPosse
  • Environment configuration
  • Common patterns

Primitive Layer: terraform-aws-* modules

  • Single AWS service or logical grouping
  • Reusable across projects
  • Well-documented interfaces

Application Layer: cloudless-api, cloudless-web

  • Combine primitives for common use cases
  • Include application scaffolding
  • Ready-to-use foundations

Why This Works

  • Upgradability: Replace modules when you outgrow them
  • Debuggability: Each module is small and focused
  • Reusability: Same modules across different projects
  • Transparency: No magic, every resource is explicit

The Network Effect

Each module makes the others more valuable:

  • Better modules → better foundations
  • Better foundations → more adoption
  • More adoption → more modules

Real-World Composition

Simple blog:

module "blog" {
  source = "git::https://github.com/ql4b/terraform-aws-website.git"
  fqdn = "blog.example.com"
}

API + Website:

module "api" {
  source = "git::https://github.com/ql4b/cloudless-api.git"
}

module "website" {
  source = "git::https://github.com/ql4b/cloudless-web.git"
  api_endpoint = module.api.rest_api.api_ids.prod
}

Complex system:

module "api" { source = "..." }
module "website" { source = "..." }
module "database" { source = "..." }
module "queue" { source = "..." }
module "monitoring" { source = "..." }

The Philosophy

Start simple, grow complex. Begin with single modules, compose them as needs evolve.

Own your stack. No vendor lock-in, no framework prison. Just infrastructure primitives you control.

Understand your system. Every resource is explicit, every connection is clear.

What This Enables

  • Rapid prototyping: Combine modules quickly for new ideas
  • Production scaling: Replace modules as requirements change
  • Team collaboration: Clear module boundaries and interfaces
  • Knowledge sharing: Reusable patterns across projects

The Future

More modules covering common patterns:

  • terraform-aws-database - RDS + connection pooling
  • terraform-aws-queue - SQS + DLQ setup
  • terraform-aws-cache - Redis/Memcached
  • terraform-aws-monitoring - CloudWatch + alarms

The goal: Every common AWS pattern becomes a 5-line module call.

The Bigger Picture

This isn’t just about Terraform modules. It’s about composable thinking applied to infrastructure.

Break complex systems into simple, reusable pieces. Combine them to solve real problems. Own your stack.