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:
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
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
Top comments (0)