Services Taste Better in Small Disposable Cups
summary
Claim: designing services as small, independently deployable units reduces blast radius but requires concrete boundaries and ops work. Recommends following package principles (common closure, common reuse), never share ActiveRecord models, avoid shared libraries for business logic, and treat components for independence, replacement and upgradability. Operational rules: each model in one service, automate orchestration and deployments, use unified logging and a unique request id for traceability. Adopt microservices only when cognitive limits or scale justify the added complexity.
AI-written summary · about
chapters (26)
- 0:00Intro
- 0:30Colombian Culture
- 6:29Monolith Application
- 8:26The Boundary Problem
- 10:24Package Creation Cohesion
- 13:07Boundary Problem
- 14:20Logical Division
- 15:15The Enemy of Good
- 16:11Dont Share Models
- 17:14Dont Share Code
- 18:22The Conways Law
- 19:37The Key Property
- 22:19microservices
- 23:33multiple languages
- 23:49boundaries
- 24:39unix motto
- 25:35rainbows
- 27:45troubleshooting
- 28:37human cognitive mass
- 29:15no single app can be large
- 30:05every sufficiently complex domain will require an app
- 30:54your team has to be prepared
- 31:27recap
- 32:35different programming languages
- 32:55no free launch
- 33:09cost of adopting
related talks
56mDesigning in the World of Microservices
54mServices, Services, Everywhere!
01h 01mArchitectural Principles and Practices to Build MicroServices
38mMicroservices, a bittersweet symphony
45mResponsible Microservices
01h 02mDesigning Microservices
45mMicroservices: A retrospective
01h 00mPrinciples for Building MicroServices