## Progressive Summary **Executive Summary (Layer 3)**: **Contain immature infrastructure behind an explicit perimeter — stateless, crash-tolerant workloads only; banned from data and money paths.** **Key Insight (Layer 2)**: "None of the failures ever affected any customer or funds. We are quite successful at containing Docker." **Context (Layer 1)**: The HFT Guy, Nov 2016 — fintech shop whose payment core moved ~$96.5M/month. Docker allowed on stateless web/microservices; banned from the Erlang core and all databases. **Discoverability Score**: 8/10 --- ## Atomic Insight The team neither rejected the technology nor adopted it wholesale — they drew a perimeter by workload class. Stateless web apps can crash daily without customer impact. Databases are the ultimate IO-intensive load (guaranteed kernel panic) and containers are designed NOT to hold state. The payment core never touches it. Inside the perimeter, survival doctrine: let it crash; run 3 instances (margin for two consecutive failures of the same service); put everything in auto-scaling groups so dead instances self-replace. Damage control extends socially: Docker war stories became part of onboarding — kill the "why don't we put the databases in docker?" idea before it grows. Durable principle: adopt risky technology where failure is cheap; the boundary is workload criticality, not team enthusiasm. --- *Source: [[Docker in Production (circa 2016)]] (The HFT Guy, Nov 2016 — Docker in Production: A History of Failure)*