Do proper monoliths before you do microservices!
summary
Argues that designing a well-structured monolith first avoids the pain of a distributed monolith built on a shared SQL Server and brittle HTTP chains; describes a real pipeline of web job → parsing API → processing API → public business API that became slow and cascadingly fragile, and a cloud stack using Azure Functions, Service Bus, App Service, IdentityServer and SQL Server. Notes teams are often <100, and cites an org with ~400 services where ~300 duplicated name/address data, fixed pragmatically with one person DB and 300 service-specific views and no brittle correlation ID plumbing.
AI-written summary · about
chapters (10)
- 0:00Introduction and setup
- 1:28Monoliths vs microservices debate
- 5:07Designing silos in monoliths
- 8:44Problems with distributed monoliths
- 13:51Case study of flawed microservices
- 22:01Proper monolith design approach
- 29:30Scaling from monolith to microservices
- 34:04Design vs implementation complexity
- 38:45Pragmatism in architecture
- 41:20Closing and contact
related talks
36mDo Proper Monoliths before You Do Microservices!
06mDo proper monoliths before you do microservices!
54mFrom a distributed monolith to a microservices solution
53mDon’t Build a Distributed Monolith: How to Avoid Doing Microservices Wrong
48mMicroMonolith
43mMicroMonolith - Top anti-patterns of distributed systems
42mQ&A - Monolith to Microservices
43mHow to Avoid Doing Microservices Completely Wrong
