本文由 AI 分析生成
建立時間： 2026-03-28 來源： https://nexo.sh/posts/microservices-for-startups/
Summary
Oleg Pustovit’s practitioner argument against premature microservices at startups. Enumerates the hidden costs (deployment complexity, CI/CD duplication, local dev fragility, observability overhead, test fragmentation) and makes the case for a well-structured monolith until you have real scaling bottlenecks or team size that justifies the split.
Oleg Pustovit 反對初創公司過早採用微服務的實踐論點。列舉隱藏成本（部署複雜性、CI/CD 重複、本地開發脆弱性、可觀測性開銷、測試分散），並論證在出現真正的擴展瓶頸或足以證明拆分合理的團隊規模之前，使用結構良好的單體應用更好。
Key Points
- Microservices tax table: deployment complexity → hours lost per release; local dev fragility (Docker sprawl) → slow onboarding; CI/CD duplication; cross-service coupling; observability overhead (distributed tracing); fragmented test suite
- Monoliths still work: even messy monoliths ship value; framework support (Django, Laravel, NestJS) is optimized for monolithic use; Segment reversed their microservice split due to cost
- Premature boundary problem: microservice splits ossify structure before product is validated — services split by guessed domains, not actual scaling requirements
- When microservices pay: real scaling bottlenecks, large teams (10+), independently evolving domains
- Author’s real-world case: Laravel real-estate app grew to hundreds of GB of docs + dozens of third-party integrations, never needed microservices
- Coordination tax: architecture shapes planning and estimation overhead, not just code; organizational complexity grows linearly with services
Insights
The “microservices as tax” framing is the most useful reframing of this recurring debate. The table of hidden costs is the most practical tool — it makes abstract “complexity” concrete and quantifiable in developer-hours. The Segment reversion case is important: Segment is a large, experienced team that adopted microservices deliberately and reversed the decision — it’s a stronger counter-argument than anecdotes from small teams. The distinction between “bad modularization inside a monolith” and “the monolith itself is unscalable” is precise: scalability problems usually come from code quality, not deployment topology.
Connections
Raw Excerpt
Microservices only pay off when you have real scaling bottlenecks, large teams, or independently evolving domains. Before that? You’re paying the price without getting the benefit: duplicated infra, fragile local setups, and slow iteration.