THE BIG MONOLITH
5
▫︎Big codebase
▫︎Tests take a lot of time to run
▫︎Hard to deploy isolated changes
Slide 6
Slide 6 text
THE BIG ORGANIZATION
6
▫︎Several teams
▫︎Teams might be distributed
▫︎Communication overhead
Slide 7
Slide 7 text
Breaking this app seems to be a
good idea, right?
7
Slide 8
Slide 8 text
Let’s build a Services Oriented
Architecture (SOA)…
8
Slide 9
Slide 9 text
Behold, the Distributed Monolith™!
(it’s a monolith, but distributed)
9
Slide 10
Slide 10 text
Has anyone here survived a failed
SOA implementation?
10
Slide 11
Slide 11 text
THE DISTRIBUTED MONOLITH
11
▫︎Changes to one part…
Slide 12
Slide 12 text
THE DISTRIBUTED MONOLITH
12
▫︎Break the entire system…
Slide 13
Slide 13 text
"Making changes in lots of different
places is slower, and deploying lots
of services at once is risky — both
of which we want to avoid.”
— Sam Newman
13
Slide 14
Slide 14 text
I heard Microservices are the next
big thing now…
14
Slide 15
Slide 15 text
Microservices = SOA done right
(Pssst… don’t tell anyone)
15
Slide 16
Slide 16 text
The first rule of Microservices is:
Do not build Microservices, unless…
16
Slide 17
Slide 17 text
WHEN TO BREAK THE MONOLITH
17
▫︎Big codebase
▫︎Large team
▫︎Tests take a long time to run
▫︎Hard to deploy isolated changes
▫︎Too much overhead
Slide 18
Slide 18 text
WE ARE GOING TO TALK ABOUT
18
▫︎How to model services
▫︎Integration techniques
▫︎Organizational alignment
Slide 19
Slide 19 text
HOW TO MODEL
SERVICES
19
Slide 20
Slide 20 text
LOOSE COUPLING
20
▫︎We want to deploy changes in
isolation
Slide 21
Slide 21 text
HIGH COHESION
21
▫︎We want to change related behavior
in one place
Slide 22
Slide 22 text
BOUNDED CONTEXTS
22
▫︎We want to find boundaries within
our problem domain
Slide 23
Slide 23 text
THE CELL ANALOGY
23
Boundary
(Membrane)
Hidden Model
(Nucleus)
Shared Model
(Nutrients)
Slide 24
Slide 24 text
It’s all about aligning your
services into business capabilities
24
AVOID TECHNICAL SEAMS
37
▫︎Ex: backend,
database service
▫︎Layered system
▫︎Onion architecture
Slide 38
Slide 38 text
AVOID ANEMIC SERVICES
38
▫︎Ex: CRUD-only
▫︎Start with coarse-grained services
▫︎Break them down only if necessary
Slide 39
Slide 39 text
INTEGRATION
39
Slide 40
Slide 40 text
"Making changes in lots of different
places is slower, and deploying lots
of services at once is risky — both
of which we want to avoid.”
— Sam Newman
40
SHARED LIBRARIES
59
▫︎DRY - Don’t Repeat Yourself
▫︎We want to avoid duplicating system
behavior and knowledge
▫︎Code reuse FTW, right?
Slide 60
Slide 60 text
SHARED LIBRARIES
60
▫︎Potential coupling!
▫︎Updating a library might require
changes to lots services at once
Slide 61
Slide 61 text
“The evils of too much coupling
between services are far worse
than the problems caused by code
duplication” — Sam Newman
61
Slide 62
Slide 62 text
SHARED LIBRARIES
62
▫︎Never share business logic
▫︎Use templates to bootstrap your
service
▫︎OK to share that logging library…
▫︎Independent versioning
Slide 63
Slide 63 text
63
SYNCHRONOUS VS.
ASYNCHRONOUS
Slide 64
Slide 64 text
64
REQUESTS VS. EVENTS
Slide 65
Slide 65 text
65
ORCHESTRATION VS.
CHOREOGRAPHY
Slide 66
Slide 66 text
EXAMPLE BUSINESS PROCESS
66
Slide 67
Slide 67 text
ORCHESTRATION
67
Slide 68
Slide 68 text
CHOREOGRAPHY
68
Slide 69
Slide 69 text
"Systems that tend more toward the
choreographed approach are more
loosely coupled, and are more
flexible and amenable to change.”
— Sam Newman
69
Slide 70
Slide 70 text
SERVICES AND THE
ORGANIZATION
70
Slide 71
Slide 71 text
"Organizations which design
systems are constrained to produce
designs which are copies of the
communication structures of these
organizations”
— M. Conway
71
Slide 72
Slide 72 text
Conway’s Law
72
Slide 73
Slide 73 text
TECHNOLOGY-ORIENTED TEAMS
73
Front-End Team
Back-End Team
Database Team
Slide 74
Slide 74 text
FUNCTIONAL SILOS
74
Back-End
Front-End
Database
Slide 75
Slide 75 text
LAYERED DISTRIBUTED SYSTEM
75
Slide 76
Slide 76 text
“I called this onion architecture, as
it had lots of layers and made me
cry when we had to cut through it.”
— Sam Newman
76
Slide 77
Slide 77 text
FEATURE TEAMS
77
Slide 78
Slide 78 text
FEATURE TEAMS
78
▫︎Work across several systems
▫︎Own the application lifecycle
▫︎Autonomy to make changes
Slide 79
Slide 79 text
“If you can’t feed a team with two-
pizza, it’s too large.”
— Jeff Bezos (Amazon)
79
Slide 80
Slide 80 text
BOUNDED CONTEXTS
80
Order
fulfilment Inventory
Goods
receiving
Warehouse
Domain
Slide 81
Slide 81 text
BOUNDED CONTEXTS
81
Order
fulfillment
Inventory
Goods
receiving
Warehouse
Domain
Slide 82
Slide 82 text
Teams should have complete
ownership of the services inside
their bounded contexts
82
Slide 83
Slide 83 text
WINDOWS VISTA
83
▫︎"The Influence of Organizational
Structure On Software Quality: An
Empirical Case Study"