[1] Notes on "Building Microservices"

Currently reading Building Microservices: Designing Fine-Grained Systems and trying to curate notes for myself and some greater good 😉. I'm trying to approach this in a minimalistic way keeping the essence of chapters intact.

Introduction

Small, and Focused on Doing One Thing Well

• Cohesion - To have related code grouped together.
• Enforcing SRP by Uncle BOB
  • Gather together those things that change for the same reason, and separate those things that change for different reasons.
  • Key rules
    • Small enough and no smaller.
    • Is it codebase too big to be managed by a small team?

Autonomous : Freedom to govern itself

• Golden rule: Can you make a change to a service and deploy it by itself without changing anything else?
• Decoupling is an important aspect
  • Modelling the service right
  • Choosing right good, decoupled APIs

Key benefits

Tech Heterogenity

• Performance improvement can be done easily by consuming a new stack
• Adopting new tech is easy - Start with a service with limited potential impact.

Resilience : Capacity to recover quickly

• Key : Bulkheads (Barriers between services)
• Service boundaries are obvious bulkheads
• In monolithic, everthing stops at once. We run it on multiple machines to handle this scenario.
• In microservices, building a system that handles total of failure of one service( and degrade functionality accordingly).

Scalability

• Scaling is easier for micro than monolithic service. One aspect of complete service can be scaled individually.
• On-demand provisioning (like by AWS) on pieces that need it.

Easy of deployment

• Key factors
  • Delta in subsequent releases
  • Avoiding High Risk, Large Impact deployments
• Microservices mitigates above factors' bad consequences

Organizational Alignment

• Working on any one codebase to hit the sweet spot of team size and productivity.

Composability

• Reuse of existing functionality
• Web, native application, mobile web, tablet app, or wearable device

Replacibility optimization

• Scary Legacy code - vital and risky to replace
• Small service - Low cost to replace