Skip to content

Instantly share code, notes, and snippets.

@tp-hk
Last active March 6, 2023 20:16
Show Gist options
  • Save tp-hk/63e7076c1da7741f2580a360f2cbc168 to your computer and use it in GitHub Desktop.
Save tp-hk/63e7076c1da7741f2580a360f2cbc168 to your computer and use it in GitHub Desktop.
Tech Books Summary

Monolith to Microservices (2023 H1)


1 Just Enough Microservices

...

2 Planning a Migration

  • MS is not the goal, goal might be e.g. faster delivery, team automany, break off from monolith release cycle. Need ROI calculation, ned to align with what business tries to achieve
  • Consider microservice alternatives, or try things in parallel. Alternative ideas:
    • Modular monolith
    • Vertical scaling (more powerful machine)
    • Horizontal scaling (more machines)
    • Scale up development team
    • New technology
    • Use sliders to analyze competing priorities
  • Faster delivery: should run path-to-production analysis to find the biggest blocker
  • MS: Benefits
    • More robust architecture (ability to react to expected variations) because of decomposed functionality
    • Great options for scale-up after initial success
  • MS: When's MS a bad idea
    • Unclear domain/decompose prematurely
    • Startup/greenfield project
    • Customer-installed software
    • Lack of good reason
  • Incremental migration:
    • Start somewhat small
    • The impact of decomposition will be relfected in production env, not during development
    • Easier places to experiment - start with whiteboarding
  • Where to start migration/decomposiition
    1. Develop domain model with just enough info (e.g. use event-storming)
    2. identify bounded context
    3. BC is good starting points for defining MS boundaries
    4. map out BC dependencies to determind which is easier to extract (Fig 2.6)
    5. caveat: domain model represents logical view, not how code is organized
    6. Use trade-off diagram (benefit of decomposition vs ease of decomposition) to prioritize decomposiition (Fig 2.8)
  • Reorganizing teams
    • DevOps (independent, autonumous teams)
    • Changing/improving developer skills
  • How to know if transition is working
    • Define measures to track
    • Regular checkpoints (review quantitative + qualitative measures)
    • quantitative measures e.g. number of deployments, failure rates, cycle time
    • qualitative measures e.g. team's feelings
    • Avoid sunk cost fallacy
    • Key: take small steps, be open to new approaches
  • Misc.
    • "Reuse is not a direct outcome people want. Reuse is something people hope will lead to other benefits"
    • Irreversible vs reversible decisions
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment