Slide 1
Slide 1 text
A Game of Snakes
& Ladders Called
Microservices
Dasith Wijesiriwardena
Twitter: @dasiths Web: https://dasith.me
Slide 2
Slide 2 text
Welcome!
Thanks for joining us
Slide 3
Slide 3 text
No content
Slide 4
Slide 4 text
01
Agenda
Beyond The Marketing Pitch
Microservices aren’t new
Data & Bounded Contexts
Ownership is just the beginning
Eventually Consistent
Immediately painful
Hidden Complexity
A modern Trojan horse
05
06
03
02 Organisational Challenges
Clapping with one hand
Talk Over The Wire to Me
REST, GraphQL, gRPC or event driven?
04
Slide 5
Slide 5 text
Domain
Driven
Design
• Focus on the business requirements
•Technology always comes second
Slide 6
Slide 6 text
Beyond The
Marketing Pitch
Microservices aren’t new
1
Slide 7
Slide 7 text
Promise of
Microservices
•Scalability
•Team Autonomy
•Agility
Slide 8
Slide 8 text
Promise of
Microservices
•Scalability
•Team Autonomy
•Agility
Slide 9
Slide 9 text
Promise of
Microservices
•Scalability
•Team Autonomy
•Agility
Slide 10
Slide 10 text
Promise of
Microservices
•Scalability
•Team Autonomy
•Agility
Slide 11
Slide 11 text
Promise of
Microservices
•Scalability
•Team Autonomy
•Agility
Slide 12
Slide 12 text
Do You Need
Microservices?
•Do you have a modular
monolith?
•Is the domain well
understood?
•Are you doing it for
scalability advantages?
Slide 13
Slide 13 text
Do You Need
Microservices?
•Do you have a modular
monolith?
•Is the domain well
understood?
•Are you doing it for
scalability advantages?
Slide 14
Slide 14 text
Do You Need
Microservices?
•Do you have a modular
monolith?
•Is the domain well
understood?
•Are you doing it for
scalability advantages?
Slide 15
Slide 15 text
Do You Need
Microservices?
•Do you have a modular
monolith?
•Is the domain well
understood?
•Are you doing it for
scalability advantages?
Slide 16
Slide 16 text
(Sad) History of Microservices
Slide 17
Slide 17 text
Messaging mechanism by which
OBJECTS DISTRIBUTED over a
network, can COMMUNICATE with
each other
Common Object
Request Broker Architecture
(CORBA)
Slide 18
Slide 18 text
Same Old
New Thing
• 1958 – LISP Atoms
• 1960 – Object Oriented Programming
• 1970 – Small Talk
• 1973 – Actor Model
• 1991 – CORBA
• SOA ?
Slide 19
Slide 19 text
OBJECTS with well defined
responsibilities,
COMMUNICATING over a
MEDIUM, to complete a task
Slide 20
Slide 20 text
Organisational
Challenges
Clapping with one hand
2
Slide 21
Slide 21 text
Conway's Law
Organizations which design systems ... are
constrained to produce designs which are copies
of the communication structures of these
organizations
Slide 22
Slide 22 text
• Think vertical, not horizontal
• Security? DevOps? Performance?
• Own your outcomes
• Direct communication with stake holders
Cross Functional
Teams
Slide 23
Slide 23 text
• Think vertical, not horizontal
• Security? DevOps? Performance?
• Own your outcomes
• Direct communication with stake holders
Functional
DevOps
Development
QA
Cross Functional
Teams
Slide 24
Slide 24 text
• Think vertical, not horizontal
• Security? DevOps? Performance?
• Own your outcomes
• Direct communication with stake holders
Functional
DevOps
Development
QA
Cross Functional
Teams
Slide 25
Slide 25 text
• Think vertical, not horizontal
• Security? DevOps? Performance?
• Own your outcomes
• Direct communication with stake holders
Cross Functional
Teams
Slide 26
Slide 26 text
Cross Functional
Teams
• Think vertical, not horizontal
• Security? DevOps? Performance?
• Own your outcomes
• Direct communication with stake holders
Slide 27
Slide 27 text
Death by Polyglot
•Mastery Productivity
• Resume driven development
Slide 28
Slide 28 text
Frameworks
•Avoid! Avoid! Avoid!
•Share only the bare
minimum
Slide 29
Slide 29 text
•Avoid! Avoid! Avoid!
•Share only the bare
minimum
Frameworks
Slide 30
Slide 30 text
Data & Bounded
Contexts
Ownership is just the beginning
3
Slide 31
Slide 31 text
Ownership
Once upon a time…
One monolith, one data store
Slide 32
Slide 32 text
Ownership
Let’s do microservices…
Slide 33
Slide 33 text
Ownership
Let’s do microservices…
without thinking about data
Slide 34
Slide 34 text
Ownership
Bad: No clear ownership
Slide 35
Slide 35 text
Ownership
Make a field
optional
Bad: No clear ownership
Slide 36
Slide 36 text
Ownership
Make a field
optional
Bad: No clear ownership
Slide 37
Slide 37 text
Ownership
Make a field
optional
Bad: No clear ownership
Slide 38
Slide 38 text
OBJECTS with well defined
responsibilities,
COMMUNICATING over a
MEDIUM, to complete a task
Slide 39
Slide 39 text
Ownership
Suppliers
Machines
Customers
Good: One microservice
owns each table or entity
Slide 40
Slide 40 text
Ownership
Better:
• Owned data store
• External access via interface
Machines Customers Suppliers
Slide 41
Slide 41 text
Ownership
Better:
• Owned data store
• External access via interface
Machines Customers Suppliers
Scalability
Slide 42
Slide 42 text
Ownership
Best: Clear ownership of its
own world view (bounded
context)
Slide 43
Slide 43 text
Ownership
Best: Clear ownership of its
own world view (bounded
context)
Scalability,
Agility,
Team Autonomy
Slide 44
Slide 44 text
Distributed
Transactions
Looking for two phase
commit (2PC) ?
Slide 45
Slide 45 text
Distributed
Transactions
Hint: You have incorrect
bounded contexts
Slide 46
Slide 46 text
Talk Over The
Wire to Me
REST, GraphQL, gRPC or event driven?
4
Slide 47
Slide 47 text
OBJECTS with well defined
responsibilities,
COMMUNICATING over a
MEDIUM, to complete a task
Slide 48
Slide 48 text
Medium of
Transport
Makes all the difference
Slide 49
Slide 49 text
Medium of
Transport
Safety of in-process calls
Slide 50
Slide 50 text
Medium of
Transport
Uncertainty of network calls
Slide 51
Slide 51 text
Medium of
Transport
Closer look at the network
Slide 52
Slide 52 text
Did You Assume?
•Network is reliable
•Latency is zero
•Infinite bandwidth
•No overheads
•Is secure
Slide 53
Slide 53 text
Did You Assume?
•Network is reliable
•Latency is zero
•Infinite bandwidth
•No overheads
•Is secure
Slide 54
Slide 54 text
Designing
Your API
So many choices
Your Footer Here
Slide 55
Slide 55 text
REST
• Simple
• Suitable for CRUD
• Domain comes first
• OpenAPI (Swagger) ⟹ Great fit
for public facing interface
Slide 56
Slide 56 text
GraphQL
• Heterogeneous data
requirements? Great!
• Not just for querying
• Subscriptions
• Mutations
Slide 57
Slide 57 text
gRPC :
Universal RPC framework
• HTTP/2 and Protobuf
• Suitable for actions heavy APIs
• Contract unlikely to change? Good!
• Few well known clients? Great!
• Polyglot environment? Great!
Slide 58
Slide 58 text
Know Your
Audience
Sequential vs Event Driven API
Your Footer Here
Slide 59
Slide 59 text
Sequential
Communication
•Request + Response
•Great for querying
•Simple workflow
Slide 60
Slide 60 text
But, Also
Think About…
•Tightly coupled external
dependencies
•Owning your SLA
•If (when) dependencies fail?
• Retrying, Circuit Breaker etc.
Slide 61
Slide 61 text
But, Also
Think About…
•Tightly coupled external
dependencies
•Owning your SLA
•If (when) dependencies fail?
• Retrying, Circuit Breaker etc.
Slide 62
Slide 62 text
Event Driven
•Publish + Subscribe
•Loosely coupled
•Scalable
•Greater resiliency
(Dead letter queues etc.)
Slide 63
Slide 63 text
Event Driven
•Publish + Subscribe
•Loosely coupled
•Scalable
•Greater resiliency
(Dead letter queues etc.)
Scalability,
Resiliency
Slide 64
Slide 64 text
•Delivery guarantee
• Idempotent Handlers?
•Versioning
•Payload size
•Eventual consistency
But, Also
Think About…
Slide 65
Slide 65 text
•Delivery guarantee
• Idempotent Handlers?
•Versioning
•Payload size
•Eventual consistency
But, Also
Think About…
Slide 66
Slide 66 text
But, Also
Think About…
•Delivery guarantee
• Idempotent Handlers?
•Versioning
•Payload size
•Eventual consistency
Slide 67
Slide 67 text
Eventually
Consistent
Immediately painful
5
Slide 68
Slide 68 text
OBJECTS with well defined
responsibilities,
COMMUNICATING over a
MEDIUM, to complete a task
Slide 69
Slide 69 text
Transaction
Safety Wheels
Not for highly available
distributed systems
Your Footer Here
Slide 70
Slide 70 text
Race Conditions
• Don’t try to prevent
• Compensate instead
https://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html
Gregor Hohpe
Slide 71
Slide 71 text
Race Conditions
• Look to the real world
• Dig deeper into the domain
http://udidahan.com/2010/08/31/race-conditions-dont-exist/
Slide 72
Slide 72 text
Transactions
Tempted to use distributed
transactions to prevent
race conditions?
Slide 73
Slide 73 text
Transactions
Tempted to use distributed
transactions to prevent
race conditions?
Don’t do it *
Slide 74
Slide 74 text
NewSQL
Promises “highly” available
databases with strict
consistency.
Slide 75
Slide 75 text
NewSQL & CAP Theorem
• https://www.microsoft.com/en-
us/research/publication/transactions-distributed-actors-cloud-2/
• https://cloud.google.com/blog/products/gcp/inside-cloud-
spanner-and-the-cap-theorem
• https://www.cockroachlabs.com/blog/limits-of-the-cap-
theorem/
Slide 76
Slide 76 text
Hidden
Complexity
A modern Trojan horse
6
Slide 77
Slide 77 text
UI Monolith
The real bottleneck
Your Footer Here
Slide 78
Slide 78 text
UI Monolith
Slide 79
Slide 79 text
UI Monolith
Bottleneck
Slide 80
Slide 80 text
Micro Front-ends
Slide 81
Slide 81 text
Micro Front-ends
Scalability,
Agility,
Team Autonomy
Slide 82
Slide 82 text
Be Careful…
• Too many micro front-
ends large payload
• Framework
incompatibilities
Slide 83
Slide 83 text
Be Careful…
• Too many micro front-
ends large payload
• Framework
incompatibilities
Slide 84
Slide 84 text
Distributed
Monolith
Worst of two worlds
Your Footer Here
Slide 85
Slide 85 text
Distributed
Monolith
• You’ve distributed the logic
of your monolith? That
was the plan.
• But they can’t function
without each other? Bad!
Slide 86
Slide 86 text
Distributed
Monolith
Slide 87
Slide 87 text
Distributed
Monolith
Slide 88
Slide 88 text
Distributed
Monolith
Slide 89
Slide 89 text
Distributed
Monolith
Slide 90
Slide 90 text
Distributed
Monolith
Slide 91
Slide 91 text
Distributed
Monolith
Slide 92
Slide 92 text
Distributed
Monolith
Slide 93
Slide 93 text
Distributed
Monolith
• Complexity of a distributed
system
• Downsides of a Monolith
Slide 94
Slide 94 text
Distributed
Monolith
• Complexity of a distributed
system
• Downsides of a Monolith
Slide 95
Slide 95 text
Pains of
Distributed
Systems
Figuring out the
domain is just the
beginning
Your Footer Here
Slide 96
Slide 96 text
Inter-Microservice
Communication
Slide 97
Slide 97 text
Cross Cutting
Concerns
• Service Discovery
• Load Balancing
•Circuit Breaker, Retry etc
• Dynamic Routing
•Security & Access Control
• Monitoring & Tracing
Slide 98
Slide 98 text
Delegate to
Sidecar
https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar
Slide 99
Slide 99 text
Service Mesh
https://www.nginx.com/blog/what-is-a-service-mesh/
Slide 100
Slide 100 text
What About?
• Deployment
• Auto scaling
•Chaos engineering
etc.. etc.. etc..
Slide 101
Slide 101 text
Conclusion
What should you take away
from this?
Slide 102
Slide 102 text
Let’s Revisit
•Do you have a modular
monolith?
•Is the domain well
understood?
•Are you doing it for
scalability advantages?
Slide 103
Slide 103 text
Let’s Revisit
•Do you have a modular
monolith?
•Is the domain well
understood?
•Are you doing it for
scalability advantages?
Slide 104
Slide 104 text
Let’s Revisit
•Do you have a modular
monolith?
•Is the domain well
understood?
•Are you doing it for
scalability advantages?
Slide 105
Slide 105 text
Let’s Revisit
•Do you have a modular
monolith?
•Is the domain well
understood?
•Are you doing it for
scalability advantages?
Slide 106
Slide 106 text
Monolith’s Have
Their Place
Solve business problems first,
Technology second…
Your Footer Here
Slide 107
Slide 107 text
It’s a Journey
Rome wasn’t built in a day…
Your Footer Here
Slide 108
Slide 108 text
Learn From The
Past Experiences
Microservices aren’t new
Your Footer Here
Slide 109
Slide 109 text
Your Footer Here
Do It For The
Right Reasons
Timing is everything…
Slide 110
Slide 110 text
No content
Slide 111
Slide 111 text
Thank You!
Do you have any questions?
J O H N S H O W E E T
P R E S E N T A T I O N E X P E R T
@dasiths
dasith.me