- [[#Core Definition|Core Definition]] - [[#The 4 Key Concepts|The 4 Key Concepts]] - [[#The 4 Key Concepts#1. Independent Deployability|1. Independent Deployability]] - [[#The 4 Key Concepts#2. Business Domain Modeling|2. Business Domain Modeling]] - [[#The 4 Key Concepts#3. Own Their Own State|3. Own Their Own State]] - [[#The 4 Key Concepts#4. Size Is Overrated|4. Size Is Overrated]] - [[#Monolith Types (The Alternatives)|Monolith Types (The Alternatives)]] - [[#Monolith Types (The Alternatives)#Key Insight|Key Insight]] - [[#Conway's Law|Conway's Law]] - [[#Enabling Technology|Enabling Technology]] - [[#Benefits of Microservices|Benefits of Microservices]] - [[#Pain Points|Pain Points]] - [[#When To Use Microservices|When To Use Microservices]] - [[#When To Use Microservices#Avoid For|Avoid For]] - [[#When To Use Microservices#Good For|Good For]] - [[#Discussion Questions|Discussion Questions]] ## Core Definition Microservices are **independently releasable services modeled around a business domain**. They're a specific, opinionated form of Service-Oriented Architecture (SOA) where: - Each service encapsulates functionality exposed via network endpoints (REST, queues, etc.) - Internal implementation details (tech stack, database) are hidden from consumers - **Information hiding** is the key principle --- ## The 4 Key Concepts ### 1. Independent Deployability The most important takeaway from the entire book. You should be able to deploy one service without touching any others. This forces you to get coupling and contracts right. > "If you take only one thing from this book and from the concept of microservices in general, it should be this: ensure that you embrace the concept of independent deployability of your microservices." ### 2. Business Domain Modeling Services should be vertical slices of business capability, not horizontal technical layers. A "Customer Profile" service beats splitting into separate UI/backend/database tiers. - Use domain-driven design to find boundaries - Cross-service changes are expensive, so minimize them - Prioritize cohesion of business functionality over technical functionality ### 3. Own Their Own State No shared databases. If Service A needs Service B's data, it *asks* Service B for it. - Encapsulation of data (like in OOP) enables information hiding - Clean separation between internal implementation and external contract - Reduces coupling, enables independent deployability ### 4. Size Is Overrated "How big should a microservice be?" is the wrong question. Focus on: - Well-defined boundaries - Manageability for your team - "As small an interface as possible" (Chris Richardson) --- ## Monolith Types (The Alternatives) | Type | Description | Notes | |------|-------------|-------| | **Single-process monolith** | All code in one deployable unit | Valid choice for many orgs | | **Modular monolith** | Internal modules, still deployed together | Shopify does this well | | **Distributed monolith** | Multiple services that *must* deploy together | Worst of both worlds | ### Key Insight > "A monolithic architecture is a choice, and a valid one at that. I'd go further and say that in my opinion it is the sensible default choice as an architectural style." --- ## Conway's Law > "Organizations which design systems...are constrained to produce designs which are copies of the communication structures of these organizations." - Three-tiered architecture exists because we grouped people by technical skill - Microservices let you align architecture to business domains - Stream-aligned teams own end-to-end slices of functionality --- ## Enabling Technology | Technology | Purpose | Priority | |------------|---------|----------| | **Log aggregation** | Central log collection and analysis | Essential prerequisite | | **Distributed tracing** | Trace requests across services (Jaeger, Honeycomb) | Important as you scale | | **Containers/Kubernetes** | Isolated execution, orchestration | Don't rush into these | | **Streaming (Kafka)** | Real-time data sharing between services | As needed | | **Serverless/Cloud** | Managed services, reduced operational burden | As needed | --- ## Benefits of Microservices 1. **Technology heterogeneity** — Pick the right tool for each job 2. **Robustness** — Service boundaries act as bulkheads 3. **Independent scaling** — Scale only what needs scaling 4. **Faster deployment** — Smaller changes, lower risk, faster releases 5. **Organizational alignment** — Smaller teams on smaller codebases 6. **Composability** — Reuse functionality across different channels --- ## Pain Points | Challenge | Description | |-----------|-------------| | **Developer experience** | Hard to run everything locally as services multiply | | **Technology overload** | Temptation to adopt too much new tech at once | | **Cost** | More infrastructure, learning curve slows delivery short-term | | **Reporting** | Data scattered across schemas; need new approaches | | **Monitoring** | Failure modes more complex than binary up/down | | **Security** | More data in transit, more endpoints to protect | | **Testing** | End-to-end tests become expensive and flaky | | **Latency** | Network calls replace in-process calls | | **Data consistency** | No easy distributed transactions; need sagas, eventual consistency | --- ## When To Use Microservices ### Avoid For - **Brand-new products/startups** — Domain not yet stable; boundaries will shift - **Small teams** — The "microservice tax" consumes too much bandwidth - **Customer-deployed software** — Can't expect customers to run Kubernetes ### Good For - **Larger organizations** — Reduces delivery contention - **SaaS products** — Need 24/7 deployment capability - **Cloud-native systems** — Match services to cloud offerings - **Digital transformation** — Unlock functionality from legacy systems --- ## Discussion Questions 1. What's the difference between SOA and microservices? 2. Why is independent deployability the "one thing" to take from this book? 3. How does Conway's Law relate to three-tiered vs. business-domain architecture? 4. Why are shared databases so problematic for microservices? 5. When would a modular monolith be preferable to microservices? 6. What's the "microservice tax" and why does it hit small teams hardest? 7. What enabling technology does the author consider a *prerequisite* before adopting microservices? 8. The author says microservices "buy you options." What does this mean, and what's the tradeoff? 9. Why does the author recommend incremental migration rather than a big-bang rewrite? 10. How do you decide if your organization is ready for microservices?