MicroMonolith
Top anti-patterns of distributed systems
@francmichal
www.mfranc.com
Lead Dev @
Poland -> London
<3 Vim
@francmichal
www.mfranc.com
Michal Franc
Not this presentation
-
not selling anything
-
not selling microservicses
Agenda
-
Monolith -> Microservices
-
Anti-patterns
The rise of microservices
Microservices are on the rise
But this is not a silver bullet!
Adopting micro services is a long learning process and big investment
journey to microservices
-
Tech 4 Good
-
Social Giving Platform
-
10+ mln active users
-
400+ gbp mln donations
1
Monolith in Numbers
-
120+ projects
-
60 min deploy time
-
one DB 1TB+
-
2-3 week release
-> Transformation ->
Microservices
in Numbers
-
120+ microservices
-
5-10 minutes deploy time
-
CouchDB, Redis, DynamoDB, EventStore, SQL
-
Daily releases ( 300+ so far )
What can we share ?
Antipatterns
- MicroMonolith
- One DB to rule them all
- HTTP all the things
-
MacroService
-
MicroOverload
MicroMonolith
The Promise
That was theory
The Big Ball Of Mud
Functional
Beautiful
Mess
Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations
— M. Conway
Conway's law
Why ?
- Complexity
- Chaos
- Development / Exploration
Distributed - Ball of Mud
First iteration
MicroMonolith
- Team structure
- Culture
- Previous experience
Direct translation of legacy system will lead to the same system with new problems
New problem
Network
-
latency
-
complexity
-
debbuging problems
-
security
Reboot
- new approach
- explored domain
- DDD-lite
- training
One DB to rule them all
Single point of failure
Natural step from monolith DB
Good Idea ?
Multiple Databases
New problems
data sharing
queries
polyglot persistence
Good Enough
Options
-
table per service
-
schema per service
-
event sourcing
HTTP all the things
Messaging
DB sync
Event Sourcing
MacroService
It is natural process for the service to grow with time
Useful split example
Why this split is useful
-
Scaling
-
Stability
-
Lower complexity
-
Releases
-
Costs
MicroOverload
More Microservices
leads to increased
complexity
cost
maintenance
more network problems
Just like building 'good enough' software is difficult. Finding balance in number of microservices is also difficult.
ScaleUp perf
ScaleDown money
Be prepared for increased costs
Mess in services add running costs on top of that
1
Mess in code leads to development / maintenance costs
Planned downtime
Containers - Docker
Controlling size
Summary
Is Monolith first approach that bad ?
Adopting microservices requires changes in the team structure and culture
Simple requests through HTTP are not enough
QA
The End
@francmichal
www.mfranc.com
Micromonolith
By Michal Franc
