Building and evolving microservices: lessons from the frontlines
summary
Six years of frontline experience yields concrete lessons: an early project fails after two months because teams deliver infrastructure instead of value; successful migrations use event streams and CQRS with read-only replicas, start with low-risk slices, and split an ESB into five services rather than orchestrate everything. Automation, infra-as-code, health checks and monitoring cut lead time — commit-to-prod and the time to create a new service drop (from three months to about half a day). Expect eventual consistency, use bulkheads and circuit breakers, and measure everything.
AI-written summary · about
chapters (24)
- 0:00Intro
- 0:19About me
- 2:12Microservices
- 5:11Organised around capabilities
- 5:39Culture of automation
- 5:57Smart endpoints & dumb pipes
- 7:40Decentralized data
- 14:57Complexity
- 17:38Adoption premium
- 20:14Splitting the monolith
- 21:00Monolith in a box ...or a coffin :
- 24:28Splitting the ESB
- 30:09Strategy
- 32:04Micro & macro architecture
- 33:08Conway's law ...in reality
- 33:37Service fit and evolution FITNESS FUNCTION FIT
- 34:41How service templates look like?
- 36:55Infrastructure as code
- 37:26Testing
- 37:39Test pyramid
- 38:21Consumer Driven Contracts
- 39:54Patterns of resilience
- 40:50Incident management
- 42:38How to focus on practices?
related talks
57m6 Lessons I Learned on My Journey from Monolith to Microservices
58mWhat has 4 years of AWS Microservices taught me?
57mEmbracing Microservices
27mThe technical journey to microservices
45mMicroservices: A retrospective
52mMicroservices: A Utopian Mystery
40mMicroservices: 5 things I wish I'd known
35mSeven years with microservices: a critical review