building systems that are never done - GOTO...
120
Transcript of building systems that are never done - GOTO...
2
never done
3
never done
Incomplete
adjective not having all the necessary or appropriate parts
3
never done
Incomplete
adjective not having all the necessary or appropriate parts
4
never done
4
“This, milord, is my family's axe. We have owned it for almost nine hundred years, see. Of course, sometimes it needed a new blade. And sometimes it has required a new handle, new designs on the metalwork, a little refreshing of the ornamentation . . . but is this not the nine hundred-year-old axe of my family? And because it has changed gently over time, it is still a pretty good axe, y'know. Pretty good.”
never done
5
microservices should be:
cheap to replace
and should allow us to go as “fast as possible”?
quick to scale
able to withstand failure
6
“the first post-devops architectural style”Neal Ford
7
replaceable component architecturesDan North
8
the future is scary
9
"ever accelerating progress of technology and changes in the mode of human life, which gives the appearance of approaching some essential singularity in the history of the race beyond which human affairs, as we know them, could not continue”
John von Neumann, as recorded by Ulam, 1958
10
11
Singularity
11
SingularityJavaScript
11
SingularityJavaScript
Container
11
SingularityJavaScriptLog aggregation
Container
12
even closer to home
HOW WE DESIGN SOFTWARE IS CHANGING
13
14
15
Hardest things to do:
15
Hardest things to do: End-to-end testing
15
Hardest things to do: End-to-end testing
Independent deployment
15
Hardest things to do: End-to-end testing
Independent deployment
Service versioning / evolution
TESTING MICROSERVICES IS HARD
16
Service A
Service
Large
Medium
Small
TESTING MICROSERVICES IS HARD
16
Service A
Service
Large
Medium
Small
Service Stub
TESTING MICROSERVICES IS HARD
16
Service A
Large
Medium
Small
INTEGRATING MICROSERVICES IS HARD
17
INTEGRATING MICROSERVICES IS HARD
17
Integration Test
INTEGRATING MICROSERVICES IS HARD
17
Integration Test Prod…
INTEGRATING MICROSERVICES IS HARD
17
Integration Test Prod…
INTEGRATING MICROSERVICES IS HARD
17
Integration Test Prod…
INTEGRATING MICROSERVICES IS HARD
17
Integration Test Prod…
18
<thinks>
19
agile
XPTDD
BDD
YAGNI
DRY
SOLID
Continuous Delivery
Refactoring
GoF
GRASP
emergent design
World of Warcraft
KISS
20
20
Gemini Project, Rogallo wing
Source: wikipedia.org
21
<thinks>
22
Gemini Project, Rogallo wing
Source: wikipedia.org
it’s turtles all the way down
23
agile
XPTDD
BDD
YAGNI
DRY
SOLID
Continuous Delivery
Refactoring
GoF
GRASP
emergent design
World of Warcraft
KISS
24
agile
XPTDD
BDDYAGNIDRY
SOLID
Continuous Delivery
Refactoring
GoF
GRASP
emergent design
World of Warcraft
KISS
2626
2727
2828
2929
Build out services as you need
them
30
agile
XPTDD
BDD
YAGNI
DRY
SOLID
Continuous Delivery
Refactoring
GoFGRASPemergent design
World of Warcraft
KISS
31
32
Fulfilment
Retail
33
Fulfilment Retail
34
Fulfilment Retail
35
Fulfilment Retail
36
Fulfilment Retail
High cohesion
Low coupling
37
(incidentally, if you were playing the Conway’s law lottery, that’s
when you number came up)
38
agile
XPTDD
BDD
YAGNI
DRYSOLID
Continuous Delivery
Refactoring
GoF
GRASP
emergent design
World of Warcraft
KISS
39
“Every piece of knowledge must have a single, unambiguous, authoritative
representation within a system”
Dave Thomas, interviewed by Bill Venners (2003-10-10). "Orthogonality and the DRY Principle". Retrieved 2006-12-01.
4040
shared binary dependencies
∆ dep ⇒ ∆S1 + ∆S2 + … + ∆Sn
41
git clone https://github.com/boicy/service-template
(note this doesn’t exist)
42
43
DRY within services
duplication between services
44
agile
XP
TDDBDD
YAGNI
DRY
SOLID
Continuous Delivery
Refactoring
GoF
GRASP
emergent design
World of Warcraft
KISS
45
45
Small
Medium
Large
46
“The London school of Test Driven Development”
Mike Feathers
47
should we write unit tests?
48
should bother with test driving our code if we are going to throw it away?
49
Nat Pryce Steve Freeman Dan North Sydney ‘Hoppalong’ Redelinghuys Jim Webber Ian Robinson Ivan Moore Liz Keogh Simon Stewart Jez Humble Dave Farley Jay Fields Dan Worthington-Bodart Joe Walnes
50
http://moleseyhill.com/blog/2009/08/27/dreyfus-model/
should we write unit tests?
51
personally I think it’s more important than *ever*
52
agile
XPTDD
BDD
YAGNI
DRY
Continuous Delivery
Refactoring
GoF
GRASP
emergent design
World of Warcraft
KISS
SRP
53
a class should be no bigger than my head
5454
a:Class
5555
a:Class
a:Class
a:Class
a:Class
5656
5757
58
SRP
a service should be no bigger than
my head
59
agile
XPTDD
BDD
YAGNI
DRY
SOLID
Continuous Delivery
Refactoring
GoF
GRASP
emergent design
World of Warcraft
KISS
60
61
WWJD?
61
WWJD?(what would Joe do?)
62
63
cron, python, boto, pydot, graphviz
63
cron, python, boto, pydot, graphviz
64
cron, python, boto, pydot, graphviz
Do the simplest thing possible
65
integration and deployment
66
66
66
SEMANTIC MONITORING
67
service bservice a
67
service bservice a
Small
Medium
Large
67
service bservice a
Small
Medium
Large
67
service bservice a
Small
Medium
LargeConsumer Driven Contracts
68
Customer ServiceWeb Shop
68
Customer ServiceWeb Shop
Expectations
68
Customer ServiceWeb Shop
Expectations
68
Customer ServiceWeb Shop
Expectations
Prod
68
Customer ServiceWeb Shop
Expectations
Prod
69
70
Prod
Prod
Prod
Prod
QA
Good Monitoring
Fast Remediation
TESTING IN PRODUCTION
71
integration environment
the death of the
72
production != live
73
CHANGING SERVICES INDEPENDENTLY
74
CHANGING SERVICES INDEPENDENTLY
What is the blast radius of the change?
74
CHANGING SERVICES INDEPENDENTLY
What is the blast radius of the change?
Limited to your team?
74
CHANGING SERVICES INDEPENDENTLY
What is the blast radius of the change?
business capability?Limited to your team?
74
CHANGING SERVICES INDEPENDENTLY
What is the blast radius of the change?
business capability?organisation?
Limited to your team?
75Thomas J. Allen, 1977
76
0 10 20 30 40 50 60 70 80 90 1000
0.05
0.10
0.15
0.20
0.25
0.30
m
Probability of weekly interaction
x
x x
x xxxxxxxxx
x
x xx
x xx x
The effect of distance on communication
77
Low change rate
inter-company integration
High stability
Semantic Versioning
Contract Testing
Tolerant Reader
“Conversational change”
78
higher change rate
inter-team integration
lower stability
Semantic Versioning
Contract Testing
Tolerant Reader
“Conversational change”
79
highest change rate
intra-team
lowest stability
Semantic Versioning
Contract Testing
Tolerant Reader
“Conversational change”
80
the future is scary
we are learning how to:
Craft my families axe
Deploy small services independently
Test microservices in isolation Test microservices in production
82
the future is bright
83
we have old techniques that apply:
SRP GRASP YAGNI KISS TDD DRY
and new techniques to apply:
Consumer Driven Contracts Semantic Monitoring Semantic Versioning Testing in Production Failure Isolation
85
85
do the simplest thing possible
