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

Loading comments...

More from Michal Franc