Traps on the Path to Microservices
summary
Claim: adopting microservices without organizational readiness often increases architecture complexity and yields a distributed monolith. Implementation specifics: a RESTful façade is added to a third‑party vendor, teams run daily ETLs to keep data in sync, debugging without log aggregation takes several hours, and deploys collapse into a monthly gate where QA controls releases. Remedies shown: teams own their build and deploy pipelines, use contract tests or a dev workstation, and extract functionality incrementally via the strangler pattern.
AI-written summary · about
chapters (16)
- 0:00Start
- 3:30Under Estimating the Cost of a Micro Service
- 4:05Operational Costs
- 4:57Scaling
- 5:19Build and Deploy Pipelines
- 5:48Integration Costs
- 6:21Error Handling
- 7:08Developers Costs
- 8:13A Dev Workstation
- 8:50Contract Tests
- 10:20Maximize the Benefits of every Micro Service
- 10:30Benefits of Micro Services
- 11:53Over Centralization
- 12:07Too Much Shared Code
- 19:23Mitigating Database Integration
- 20:43Parting Words
related talks
27mThe technical journey to microservices
43mHow to Avoid Doing Microservices Completely Wrong
53mDon’t Build a Distributed Monolith: How to Avoid Doing Microservices Wrong
30mHow to Fail at Building Modern Microservices
40m10 tips for failing at microservices
55mMicroservices, Where Did It All Go Wrong
46mSurviving microservices
44mMicroservices, Where Did It All Go Wrong