A spectrum of patterns for how much infrastructure to put in a single deployment stack. Each step toward finer granularity increases deployment independence but adds integration complexity. ## The Spectrum ``` ← Simpler, more coupled More independent, more complex → Full System → Application Group → Single Service → Micro Stacks Stack Stack Stack ``` ## Full System Stack All infrastructure for the entire system in one stack. Simple to start; avoids integration complexity. Good for early-stage systems. Becomes the Monolithic Stack antipattern as systems grow. ## Monolithic Stack (Antipattern) A stack that has grown too large to manage effectively. Symptoms: - Changes to one workload's infra risk affecting all others (high coupling) - Long deployment times → poor DORA metrics (lead time, deploy frequency) - CI builds take too long → teams resort to feature branches → coordination overhead - **Telltale sign**: habitual use of feature branches on a single infrastructure component Fix: decompose into Application Group Stacks or Single Service Stacks. ## Application Group Stack All infrastructure for a group of related services in one stack. Services grouped by: combined capability delivery, or single team ownership (Conway's Law alignment). Sweet spot for teams with 2-5 services that change together. Balances isolation and simplicity. ## Single Service Stack One stack per service. Aligns stack boundaries with workload ownership — each team owns its infrastructure end-to-end. Limits blast radius to one service. Downside: code duplication across stacks (each has its own DB code). Mitigated by shared libraries or a shared stack project with multiple instances (see [[Infrastructure Sharing Code vs Instance]]). Well-suited for microservice architectures and autonomous teams. ## Micro Stacks A single service's infrastructure split into multiple stacks by lifecycle/change cadence. Example: separate DB stack from compute stack for one service. Patching compute no longer triggers DB backup + restore cycle. Tradeoff: more independently deployable components, but more complex testing, delivery, and integration to manage. ## Shared Stack Provisions infrastructure used by multiple workloads (API gateway, shared network, DNS). Necessary for genuinely cross-cutting concerns — use sparingly, as it creates deployment dependencies between workloads. --- *Source: [[Infrastructure as Code, 3rd Edition — Kief Morris]] (Kief Morris, O'Reilly 2025) — Ch 7 — Designing Deployable Infrastructure Stacks*