Why I Wouldn't Use MicroServices
summary
Argues microservices are often the wrong choice for law-driven domains and shows concrete results: a Norwegian benefits system models the law with 320 concepts and runs over 3,000 assertions in ~20 seconds, deploys via continuous delivery at 12–14 deployments a day, and uses Kotlin, Kafka event buses, React UI, a mediator pattern and a simple task manager. Microservices appear only at unstable external interfaces and a separate fraud engine uses microservices; TDD, pair/mob programming and event-based integration make the architecture work.
AI-written summary · about
chapters (14)
- 0:00Intro
- 2:07Requirements uncertainty
- 3:08Types of problems
- 6:17Fuzzy problems
- 7:48Norwegian National Benefits
- 9:28The Team
- 10:06Continuous Delivery
- 11:31Architecture
- 17:30Conclusion
- 18:20Unemployment Benefits
- 19:12Building Continuous Delivery
- 19:38Making Decisions
- 24:30Open Source
- 24:56Problems
related talks
48mChallenges in Implementing MicroServices
54mThe Long Sad History of Microservices
38mMicroservices, a bittersweet symphony
26mPros/Cons of Microservices
52mWhat Does a Good Microservice Architecture Look Like?
49mChallenges in Implementing Microservices
20m3 reasons why micro-services aren't the miracle cure
23mWhy You Had a Bad Time With Microservices