The six obstacles of moving to microservices and how to deal with them
summary
A migration from a giant monolith to 25–30 microservices takes roughly a year and ends up working but costs that year in rework and coordination; the project adopts an event-driven architecture with event-storming and tracing (Zipkin suggested) and keeps a visible microservices map plus a decision log to manage synchronous calls, common guidelines, and postponed infra like service discovery, load balancing and centralized logging; outcome is production success but only after repeated refactors, strict visibility and limits on team size.
AI-written summary · about
chapters (6)
- 0:00Introduction
- 0:22The book-reading cult
- 4:49Service coupling issues
- 10:59Common pattern phobia
- 11:53Strategic planning and adoption
- 40:56Closing thoughts
related talks
52mMicroservice Migration Roadmap
55mMigrate your company to microservices: a step by step tutorial
58mWhat has 4 years of AWS Microservices taught me?
56mHow to Survive with Microservices
52mMicroservices: A Utopian Mystery
32mSplitting the monolith
57m6 Lessons I Learned on My Journey from Monolith to Microservices
48mExtracting a microservice from a 15-year-old monolith: a one-year adventure