Lead Dev @
@francmichal
www.mfranc.com
Michal Franc
ENGINEER | LEADER | SPEAKER
Britannia Londinium
Micromonolith
Top anti-patterns of adopting distributed systems
MicroServices!
\o/
Microservices are on the rise
Microsevices are not the silver bullet
https://setandbma.files.wordpress.com/2012/05/technology-adoption.png
Sharing
Experience
Failures & Antipatterns
Adoption
-
Tech 4 Good
-
Social Giving Platform
-
20+ mln awesome users
-
3 bln $ raised
-
100k funded causes
Powered by
Monolith in Numbers
-
120+ projects
-
Multiple products
-
one repository
-
one DB 1TB+
-
60 min deploy time
-
2-3 week release ( complex )
-> Transformation ->
Costly Monolith
More Agility
Monolith
Monolith
Monolith
Monolith
Microservices
Microservices
Microservices
Microservices
in Numbers
-
120+ microservices
-
repository per service
-
5-10 minutes deploy time
-
Daily releases ( simple process )
Monolith First
Preferable ?
Antipatterns
-
MicroMonolith
-
Synchronous Integration
-
One DB to rule them all
-
Underestimating the Costs
MicroMonolith
The Big Ball Of Mud
Functional
Beautiful
Mess
The Road to
Monolith
-
Complex
-
Development / Exploration
-
Changes
-
Pressure, Good Enough
Distributed - Ball of Mud
First iteration
MicroMonolith
Micromonolith was natural effect of existing habits and experience bias
"Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"
M. Conway
Adopting microservices requires changes in the team structure and culture
Distributed system require 'distributed' teams
Micromonolith was just part of our learning process
Fail fast but learn
Synchronous Integration
HTTP / REST
Synchronous Problem
Underestimated
Network Layer
-
latency
-
complexity
-
debbuging
-
security
-
connectivity
Assume that there will be problems
You can't beat the nature of the network
Defensive design and coding
"Occasionally connected apps" @gregyoung
Asynchronous HTTP
Messaging
Middleman
Push
What about pull ?
Distributed Data
Denormalized snapshot
of state per service
Eventual Consistency
Transactions ?
'Synchronous Consumer'
Monolithic App
Hidden
Disabled - Cached Data
Distributed
App
Scalability
CRITICAL
Different features, different scale
Bringing It Together
A brief history of one product
Cached data
Static Page
No Interaction
External System - Donation
External Dependancies
Introducing Message Bus
Be Pragmatic
Where do you need scalability?
Where do you need reliability?
One DB
to rule them all
Monolithic DB
-
business logic
-
complex reports
-
business transactions
First Iteration
... Single point of failure
Natural step from monolithic DB
-
data storage type bias
-
tightly coupled services
-
non-distributed data model
Maintaining existing requirements ...
Code structure follows data model
Distributed data model will encourage distributed code
What else then ?
Good Idea?
Database per service
Multiple Databases
problems
-
data aggregation
-
joins
-
transactions
-
increased maintenance
Pragmatism
start simple
-
table per service
-
schema per service
Be careful
Monolithic DB habits
Other Team
Start Introducing
Slowly
-
Database per service
-
Database per product
-
Application Joins
Application Side Join
Underestimating
The Costs
Monolith
-
rented servers
-
prior experience
-
control
Distributed
New world
Cloud
Spending Control
Planned Downtime
Containers
Costs Monitoring
Custom build tools
Make cost control part of your deployment pipeline
Increased ops costs but ....
... decreased dev costs
... more agility
... faster time to market
Summary
It is a learning process
Share your experience
Let's get to plateau of productivity as soon as possible
Questions?
Thank you
@francmichal
www.mfranc.com
Micro Milan
By Michal Franc
