Book Notes Building Microservices - herougo/SoftwareEngineerKnowledgeRepository GitHub Wiki

Chapter 1: What Are Microservices?

Information hiding: means hiding as much information as possible

Independent deployability: means we can make a change to a microservice and deploy it without needing to deploy any other microservices

Tips for microservices

  • each microservice should have its own DB
    • if a microservice wants to access data held by another microservice, it should ask that microservice for it
  • embrace independent deployability
    • to do this we need explicit, well-defined, and stable contracts between services
  • don't worry about the size of the microservice (i.e. wrt the code base)
  • be cautious about taking on too much new technology with microservices
  • consider using a single ID for a related set of service calls

One approach is to have 3 layers: presentation, application, and data. You would have 3 corresponding teams to manage them. However, implementing a new feature would require changes in all 3 layers at once. Instead, microservices should be divided by business functionality.

Distributed monolith: as name suggests

  • In the author's experience, a distributed monolith has all the disadvantages of a distributed system, all the disadvantages of a single-process monolith, and not enough advantages of either.
  • They typically emerge in an environment in which not enough focus was placed on concepts such as information hiding and cohesion of buesiness functionality.

Delivery contention: different teams want to push functionality at different times

Advantages of microservices

  • technology heterogeneity: can decide on a stack on a per-microservice basis
  • robustness: explanation???
  • scaling: we can scale up by microservice (as opposed to more monolith instances)
  • ease of deployment: as opposed to deploying the entire monolith
  • organizational alignment: explanation???
  • composability: explanation???

Disadvantages of microservices

  • developer experience: difficult to run many microservices on a developer's machine
  • technology overload: can lead to too much technologies being used
  • short term costs (of running the software)
    • however, microservices allow teams to push more functionality which could lead to more revenue, so there's a trade-off
  • reporting: info is scattered across microservices making reporting difficult
  • monitoring and troubleshooting: monitoring is more difficult
  • security: monoliths have information flow within the process (as opposed to info flowing between microservices)
  • testing: scope of end-to-end testing is large
  • latency: data needs to be serialized, transmitted, and deserialized over networks, leading to bigger latency
  • data consistency: using multiple DBs can lead to consistency issues

Microservices not recommended for

  • new startups
  • organizations creating software that will be deployed and managed by their customers

Where microservices work well

  • allowing for more developers to work on the same system without getting in each other's way
  • Software as a service (SaaS) applications
  • organizations looking to provide services to their customers over a variety of new channels (what does channel mean in this context???)

Chapter 2: How to Model Microservices

What makes a good microservice boundary?

  • information hiding (has benefits of improved development time, comprehensibility, and flexibility)
  • high cohesion: related code should live together
  • low coupling: a change in one service should not require a change in another (that's the point of microservices)

Types of coupling (ordered from low to high)

  • domain: microservice A uses microservice B to make use B's functionality (largely unavoidable)
  • pass-through: microservice A passes data to microservice B solely because it needs to be used by another microservice further downstream (i.e. microservice C)
    • (gives examples which would be good to read)
  • common: when 2 or more microservices make use of a common set of data
  • content: upstream service reaches the internals of a downstream service and changes its internal state (e.g. directly accessing and changing another microservice's DB)

(DDD overview)

(Mapping Aggregates and Bounded Contexts to Microservices)

(The Case for DDD for Microservices)

Alternatives to Business Domain Boundaries

  • volatility: extracting logic with frequent change
  • data: nature of the data (e.g. hiding sensitive information from some microservices)
  • technology: need to use different technology for a specific microservice
  • organizational

Chapter 3: Splitting the Monolith

Advice for splitting a monolith

  • have a specific goal in mind (not just "we want microservices")
  • migrate incrementally
  • have a clear understanding of the domain before migrating

(choosing what to decompose first)

Decomposition by layer

  • code first (most common)
    • monolith and microservice both point to a single DB
  • data first

Useful Decompositional Patterns

  • Strangler Fig Pattern
    • wrapper around monolith and the microservice, which basically routes traffic to either the microservice or the monolith
  • parallel run
    • run both in parallel and compare results
  • feature toggle
    • e.g. toggle between using monolith and the microservice

Data Decomposition Concerns

  • performance (e.g. what if you need to a join across microservices?)
  • data integrity (e.g. can't have a foreign key constraint across microservices)
  • transactions (e.g. can't rely on ACID properties in a distributed system)
  • tooling ???
  • reporting database: ???