Architectural Principles and Practices to Build MicroServices
summary
Argues that microservices succeed only with domain partitioning, isolation and automation: every service owns its data so never share a database, services run as separate processes/containers, and resilience is built from day one. Enforces semantic versioning and deployment practice to spin up a new service instead of recycling running ones, accepts duplication over reuse to preserve autonomy, recommends the sidecar pattern for infra concerns, warns of higher operational cost and added complexity.
AI-written summary · about
chapters (16)
- 0:00Introduction to microservices
- 3:12What microservices really mean
- 7:29Bounded contexts and DDD
- 11:02Partitioning strategies
- 16:19Why SOA failed
- 20:15Identifying domains
- 23:26DDD upfront design
- 26:18Automation and maintenance
- 31:15Domain partitioning focus
- 33:03No shared databases
- 37:39Sidecar pattern
- 39:46Distributed architecture
- 41:14Never upgrade running services
- 47:04Monolith vs microservices
- 52:26Costs and benefits
- 55:36Q&A
related talks
01h 02mDesigning Microservices
56mDesigning in the World of Microservices
48mDesign principles to the rescue of micro-services
38mMicroservices, a bittersweet symphony
49mDDD & Microservices: At Last, Some Boundaries!
49mMicroservices: An unexpected Journey
52mI Have a Microservices Architecture and I Didn't Know.
52mWhat Does a Good Microservice Architecture Look Like?