Do Proper Monoliths before You Do Microservices!
summary
Argues for starting with a monolith designed as silos that can be peeled into services later, shows a working business-to-business API + integration API backed by SQL and Entity Framework, and demonstrates failures: shared databases creating a distributed monolith, logging fragmentation unless a single request boundary exists, and the awkward correlation-ID hack. Mentions Azure pieces (App Service, Event Grid/Service Bus/storage queues), cites 75–80 services at scale and a counterexample with 400 services where 300 replicate customer data. Overall: what was built sometimes works and sometimes breaks depending on design.
AI-written summary · about
chapters (8)
- 0:00Start
- 1:52Why Would You Go Micro Services
- 9:06Business-to-Business Api
- 9:24Integration Api
- 12:55What Happens if the Process Api Is Failing
- 16:30Logging Is Easier
- 29:49Easy Deployments
- 30:32Better Logging and Monitoring
related talks
42mDo proper monoliths before you do microservices!
06mDo proper monoliths before you do microservices!
01h 02mBuilding that glorious monolith. And carving it too.
46mLove Your Monolith
54mFrom a distributed monolith to a microservices solution
53mDon’t Build a Distributed Monolith: How to Avoid Doing Microservices Wrong
42mQ&A - Monolith to Microservices
43mMicroMonolith - Top anti-patterns of distributed systems