Building Microservices, 2nd Edition

Title: Building Microservices, 2nd Edition
Author: Sam Newman
Publication date: August 2021
Print length: 612 pages

Chapter 1

Microservices are a type of service-oriented architecture. 

Deployability is key for a microservices.
  • to ensure independent deployability, we need to make sure our microservices are loosely coupled
Having clear, stable service boundaries that don’t change when the internal implementation changes results in systems that have looser coupling and stronger cohesion.

Model services around business domains
  • it will make it easier to roll out new functionality and to recombine microservices in different ways to deliver new functionality
  • microservices should be slices of business functionality that encapsulate user interface (UI), business logic, and data
Microservices should avoid the use of shared databases
  • if a microservice wants to access data held by another microservice, it should go and ask that second microservice for the data
Microservice should be kept to the size at which it can be easily understood
  • do not worry about the size of a microservice when you are begging to use microservices
  • more important to define an appropriate boundary for you microservice
To ship software quicker:
  • instead of having a dedicated front end team, backend team, DBAs, the same team should own the UI, the back end and the data storage
    • this allows you to achieve high cohesion of business functionality 
    • a single team can have a single microservice that can expose a UI and manage state
"When all functionality in a system must be deployed together, I consider it a monolith"
  • monolith is the sensible default choice as an architectural style
When starting out with microservices, at the minimum, you should adopt log aggregation and distributed tracing

When the overhead of managing deployment begins to become a significant headache, start considering containerization of your service and the use of Kubernetes

Although with microservices we are moving away from monolithic databases, we

https://learning-oreilly-com.dclibrary.idm.oclc.org/library/view/building-microservices-2nd/9781492034018/ch01.html#idm45699546421792

Chapter 2

What makes for a good microservice boundary: information hiding, cohesion, and coupling. Cohesion applies to the relationship between things inside a boundary, whereas coupling describes the relationship between things across a boundary. 
  • By reducing the number of assumptions that one microservice makes about another microservice, we directly impact the connections between them. By keeping the number of assumptions small, it is easier to ensure that we can change one module without impacting others. If a developer changing a module has a clear understanding as to how the module is used by others, it will be easier for the developer to make changes safely in such a way that upstream callers won’t also have to change
  • So we want to find boundaries within our problem domain that help ensure related behavior is in one place and that communicate with other boundaries as loosely as possible. If the related functionality is spread across the system, we say that cohesion is weak—whereas for our microservice architectures we’re aiming for strong cohesion

Types of Coupling

Domain Coupling: Domain coupling describes a situation in which one microservice needs to interact with another microservice

  • whenever you see a single microservice depending on multiple downstream services in this way, it can be a cause for concern—it might imply a microservice that is doing too much.

Comments

Popular posts from this blog

Azure Architecture Explained

The Ethiopian Army: From Victory to Collapse, 1977-1991