Book summary: Building Microservices (2nd Edition)

Summary

During my overall IT carreer I came across different architectural design patterns where oppinions differ on the question if they’re the right ones for the problems/challanges teams are dealing with. Before reading this book I was familiar with some of the microservices concepts but it was some article (on modern architectures) that rouse my attention and introduced me to Sam Newman. At the same time I was surprised to read about the similarities between Hexagonal Architecture and microservices. But also topics like DDD, CD,CI are bound together in way that you need to take a hollistic approach to (building) microservices.

I recommend this book to anyone willing to spend some time (book has ca. 500 pages) learning about Information hiding, communication between microservices, proper teams setup, role of (IT) architects and much more. Fair enough the author emphasizes multiple time the complexity of decoupling existing services (monoliths) into smaller, independent ones (microservices). The book recommendations in each chapter also give a great hint where you can enlarge upon a specific topic.

What follows next is an ORG mode / outline style collection of notes, thoughts and quotes from the book.

Ch. 1: What are Microservices?

Definition

Microservices are independently releasable services that are modeled around a business domain. A service encapsulates functionality and makes it accessible to other services via networks.

• Microservices are a type of SOA architecture
  • service boundaries are important
  • independent deployability is key
• Microservices embrace the concept of Information hiding

Key Concepts

• Independent deployability
• Modeled around a business domain
• Owning their own state
• Size
• Flexibility
• Alignment of architecture and organization

Advantages

• Technology Heterogeneity

• Robustness
• Scaling
• Ease of Deployment
• Organizational alignment
• Composability

Pain Points

• Developer Experience
• Technology overload
• Costs
• Reporting
• Monitoring and troubleshooting
• Security
• Latency
• Data consistency

Ch. 2: How to model microservices

Information hiding

• hide as many details as possible behind a module / microservice boundary
• Parnas identified following benefits:
  • improved development time
  • comprehensibility
  • each module is isolated and therefore better to understand
  • flexibility

Cohesion

• code that changes together, stays together
• strong cohesion
  • ensure related behavior is at one place
• weak cohesion
  • related functionality is spread across the system

Coupling

• loosely coupled
  • change to one service should not require a change to another
• a loosely coupled services knows as little as it needs about the services it communicates with
  • limitation of number of different types of calls is important

Interplay of coupling and cohesion

A structure is stable if cohesion is strong and coupling is low.

• cohesion applies to the relationship between things inside a boundary
• coupling describes relationship between things across a boundary
• still: there is no best way how to organize code

Types of coupling

Domain coupling

• one microservice interacts with another microservice because it needs the functionality the other microservice provides

• considered as a loose form of coupling
• again, information hiding: Share only what you absolutely have to, and send only the absolute minimum amount of data that you need

Pass-through coupling

• one microservice passes data to some other microservice because data is needed by another microservice

Common coupling

• when 1 or 2 microservices make use of a common set of data
  • use of shared DB
  • use of shared memory/filesystem
• problem: changes to data can impact multiple microservices at once
• better solution would be to implement CRUD operations and let only 1 microservice handle shared DB operations

Content coupling

• when an upstream service reaches into internals of a downstream service anc changes its internal state

DDD

DDD stands for Domain-Driven Design.

Concepts

• Ubiquitous language
• Aggregates
• Bounded context

Event Storming

• collaborative brainstorming exercise designed to help design a domain model
• invented by Alberto Brandolini

Boundaries between microservices

There are some factors when defining clear boundaries between microservice

• volatility
• data
  • also with concern to security
• technology
• organizational
  • Layering Inside vs Layering Outside

Ch. 3: Split the monolith

• you need to have a goal before moving to microservices

  • should be a conscious decision
  • without clear understanding of what you want to achieve, you could fall into the trap of confusing activity with outcome

Decomposition patterns

• Strangler fig pattern
• Parallel run
• Feature toggles

Data Decomposition concerns

• performance
• data integrity
• transactions
• Tooling
• Reporting DB

Ch. 4: Communication styles

• styles for IPC communications
  • synchronous blocking
  • asynchronous blocking
  • request-response
  • Event-Driven Architecture
  • Common data

EDA

• events vs messages
  • event : is a fact
  • message : is a thing
  • a message contains an event

Ch. 5: Implementing communication

Criterias for ideal technology

• backward compatibility
• make your interface(s) explicit
• keep your APIs technology-agnostic
• make your service simple for the consumers
• hide internal implementation details

Technology choices

• RPC
• REST
• GraphQL
• Message brokers

API Gateway

• built on top on existing HTTP proxy products
• main function: reverse proxy
  • but also authentication, logging, rate limiting
• Examples:
  • AWS API Gateway
  • GCP API Gateway

Ch. 6: Workflow

Distributed Transactions

Two-phase Commits (2PC)

• a commit algorithm to make transactional changes in a distributed system, where multiple separate parts need to be updated

Sagas

• coordinate multiple changes in state
• but without locking resources for a long period
• involves
  • backward recovery
  • forward recovery
• allows to recover from business failures not technical ones
• when rollback is involved, maybe a compensating transaction is needed

Books

• Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
• Practical Process Automation

Ch. 7: Build

• on Continuous Integration (CI)
• how to organize artifacts
  • monorepo
  • multirepo

Ch. 8: Deployment

Principles of Microservices Deployment

• isolated execution
• focus on automation
• Infrastructure as a Code
• zero-downtime deployment
• desired state management
• progressive delivery

Ch. 10: From monitoring to obersavability

The observability of a system

• is the extenct to which you can understand the internal state of the system from external output
• monitoring is something we do
• observability
• pillars of observability

Alert fatigue

Alert fatigue—also known as alarm fatigue—is when an overwhelming number of alerts desensitizes the people tasked with responding to them, leading to missed or ignored alerts or delayed responses – Source

What makes a good alert

An alert has to be:

• relevant
• unique
• timely
• prioritized
  • give enough information to decide in which order alerts should be dealth with
• understandable
  • information has to be clear and readable
• diagnostic
  • it needs to be clear what is wrong
• advisory
  • help the operator understand what actions need to taken
• focussed
  • draw attention to the most important issues

On the importance of testing quote

“Not testing in production is like not practitioning with the full orchestra because your solo sounded fine at home”

Semantic monitoring

• compare against normal conditions
• you could use synthetic transactions
• other options
  • A/B testing
  • canary releases
  • Chaos engineering
  • parallel runs
  • smoke tests

Tools

• opentelemetry.io

Ch. 11: Security

Lifecycle of secrets

• Creation
  • How we create the secret
• Distribution
  • How do we make sure the secrets get to the right place?
• Storage
  • Is the secret stored in a way only authorized parties can access it?
• Monitoring
  • Do we know how secret is used?
• Rotations
  • Are we able to change the secret without causing problems?

Ch. 12: Resiliency

Resiliency

• defined by David D. Woods
• aspects

Ch. 14: User interfaces

Stream-aligned teams

• topologies how to build organizations, teams
• aka “full-stack teams”
• a team aligned to a single, valuable stream of work
• the team is empowered to build and deliver customer or user value as quickly and independently as possible, without requiring hand-offs to other teams to perform parts of the work

Microfrontends

• architectural style where independently deliverable frontend applications are composed into a greater whole
• possible implementations

SCS

• stands for Self-Contained Systems
• highlights

Ch. 15: Organizational structures

• Stream-aligned teams
  • concept aligns with loosely-coupled organizations (as in Accelerate)

Conways Law

“Any organization that designs a system will inevitably produce a design whose structure is a copy of the organizations communication structure” - Melvin Conway

All about people

“Whatever industry you operate in, it is all about your people, and catching them doing things right, and providing them with the confidence, the motivation, the freedom and desire to achieve their true potential” - John Timpson

Ch. 16: The evolutionary architect

Role of architects

• We should think of the role of IT architects more as town planners than architects for the built environment

Buildings and software

The comparison with software should be obvious. As our users use our software, we need to react and change. We cannot foresee everything that will happen, and so rather than plan for any eventuality, we should plan to allow for change by avoiding the urge to overspecify every last thing. Our city (the system) needs to be a good, happy place for everyone who uses it. One thing that people often forget is that our system doesn’t just accommodate users; it also accommodates developers and operations people who also have to work there, and who have the job of making sure it can change as required.

Governance

Governance ensures that enterprise objectives are achieved by evaluating stakeholder needs, conditions and options; setting direction through prioritisation and decision making; and monitoring performance, compliance and progress against agreed-on direction and objectives. – Cobit 5

Responsibilities of the evolutionary architect

• Vision
  • clearly communicated technical vision for the system that will help meet requirements of customers and organization
• Empathy
  • understand impact of decissions on customers and colleagues
• Collaboration
  • engage with as many of your pears and colleagues as possible to help define, refine and execute the vision
• Adaptability
  • tech vision changes as required by customers/organization
• Autonomy
  • balance between standardizing and enabling autonomy for your teams
• Governance
  • system being implemented fits the tech vision
  • make sure it’s easy for people to do the right thing

Book recommendations

• Building evolutionary architectures
• The software architect elevator