Microservices Smaller is Better? Eberhard Wolff Freelance - - PowerPoint PPT Presentation

▶

Feb 15, 2024 762 likes •1.26k views

Microservices Smaller is Better? Eberhard Wolff Freelance consultant & trainer http://ewolff.com Why Microservices? Eberhard Wolff - @ewolff Why Microservices? Strong modularization Sustainable Replaceability Development speed

SLIDE 1 Microservices Smaller is Better? Eberhard Wolff Freelance consultant & trainer http://ewolff.com

SLIDE 2 Eberhard Wolff - @ewolff

Why Microservices?

SLIDE 3 Eberhard Wolff - @ewolff Why Microservices? Strong modularization Replaceability Small units Sustainable Development speed Continuous Delivery Deployment less risky Free Choice of technology

SLIDE 4 Eberhard Wolff - @ewolff

Microservice  =  Micro?

SLIDE 5 Eberhard Wolff - @ewolff

10-100LOC

http://yobriefca.se/blog/ 2013/04/28/micro-service-architecture/

Smaller modules better

SLIDE 6 Eberhard Wolff - @ewolff

10-100LOC

http://yobriefca.se/blog/ 2013/04/28/micro-service-architecture/

Smaller modules better

SLIDE 7 Eberhard Wolff - @ewolff Game of Life

SLIDE 8 Eberhard Wolff - @ewolff life←{ ⍝ John Conway's "Game of Life".  ↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ ⍝ Expression for next generation.  } Game of Life in one line of APL dyalog.com LOC is really a bad metric

SLIDE 9 Eberhard Wolff - @ewolff Larger?

Microservices have an overhead
Build & deployment pipeline
Version control

SLIDE 10 Eberhard Wolff - @ewolff 1st Law of Distributed Objects

Don’t Distribute Your Objects!
Too much remote communication &
verhead
Lesson learned from CORBA etc
http://martinfowler.com/bliki/

FirstLaw.html

SLIDE 11 Eberhard Wolff - @ewolff Request Response Processing Latency Round Trip: 0,2-0,5 ms = 600.000-1.500.000 instructions@3GHz

SLIDE 12 Eberhard Wolff - @ewolff 1st Law of Distributed Objects & Microservices

Small Microservices =

lot of communication

Violates the 1st Law
Seems to work, though
http://martinfowler.com/articles/

distributed-objects- microservices.html

SLIDE 13 Eberhard Wolff - @ewolff

Too small =  too much communication

SLIDE 14 Eberhard Wolff - @ewolff

L

SLIDE 15 Eberhard Wolff - @ewolff

Again:  Why Microservices?

SLIDE 16 Eberhard Wolff - @ewolff

The main reason

SLIDE 17 Eberhard Wolff - @ewolff

Business relevant

SLIDE 18 Eberhard Wolff - @ewolff

How to scale agile? Implement more feature

SLIDE 19 Eberhard Wolff - @ewolff Conways Law

SLIDE 20 Eberhard Wolff - @ewolff The Law That I Must Not Name Architecture copies communication structures

f the organization

SLIDE 21 Eberhard Wolff - @ewolff Conway’s Law as an Enabler

Desired architecture =

project structure

Microservices belong to one team
Team should be responsible for

meaningful features

Ideal: Independent features

SLIDE 22 Eberhard Wolff - @ewolff

Each team can build and deploy features independently!

SLIDE 23 Eberhard Wolff - @ewolff

Microservices must provide a sensible set of functionality

SLIDE 24 Eberhard Wolff - @ewolff Conway’s Law & Microservice Size

Upper limit: What a (small) team

can handle

…and a meaningful set of features
Probably not too small
Lower limit: Depends on overhead /

technology

SLIDE 25 Eberhard Wolff - @ewolff Microservice = Micro?

Size doesn’t matter too much
Teams must be able to work

independently

Small enough for one team
Not too much overhead

SLIDE 26 Eberhard Wolff - @ewolff Conway’s Law Product Owner Service Feature Service

SLIDE 27 Eberhard Wolff - @ewolff

Bad architecture?    Still can’t be avoided!

SLIDE 28 Eberhard Wolff - @ewolff Conway’s Law Product Owner Service Service Feature Product Owner Communication Priority? Slow

SLIDE 29 Eberhard Wolff - @ewolff Conway’s Law

Software Interface =

Team Communication

Too much communication if you get

the architecture wrong.

Slows down the process

SLIDE 30

Collective Code Ownership

SLIDE 31 Eberhard Wolff - @ewolff Conway’s Law Product Owner Service Service Feature Product Owner Change Review Pull Request

SLIDE 32 Eberhard Wolff - @ewolff Microservice & Collective Code Ownership

Team might change any service
Reviews can still be done
…or use Pull Requests
More devs can work on a services
Resilience against personnel turnover
Faster

SLIDE 33 Eberhard Wolff - @ewolff Microservice & Collective Code Ownership

Team must understand bigger parts
f the code
Technology freedom?

SLIDE 34

Refactoring

SLIDE 35 Eberhard Wolff - @ewolff Refactoring Service Service Different libraries Different language Possibly a rewrite

SLIDE 36 Eberhard Wolff - @ewolff Limited Technology Set

Easier Refactoring
Easier to follow standards

for deployment, monitoring etc

Easier to implement e.g. resilience
Netflix uses a lot of

Java

SLIDE 37 Eberhard Wolff - @ewolff Refactoring Service Service Library Releases must be coordinated Hard to implement really reusable code Enforces same language / platform Like: really, really hard …and we want independent releases

SLIDE 38 Eberhard Wolff - @ewolff Refactoring Service Service Service Remote communication Unreliable network Slower calls Not great But best option

SLIDE 39

Number of Services will increase

SLIDE 40

Refactoring across Services hard

SLIDE 41 Eberhard Wolff - @ewolff Start BIG

Conway’s law: Upper size =

what a team can handle

Refactoring inside a service easier
…needed for agile environments
…where Microservices are used
Number will increase anyway
Tear apart easier than join

SLIDE 42 Eberhard Wolff - @ewolff If You Start Small…

You will get the architecture wrong
Functionality hard to move
Services not too large at the

beginning anyway

Fast deployment still possible

SLIDE 43

Systems can not be engineered

SLIDE 44

Systems grow.

SLIDE 45

Guide growth.

SLIDE 46

Sum Up

SLIDE 47 Eberhard Wolff - @ewolff Faster Time-to- Market Microservices Refactoring Conway’s Law Collective Code Ownership Start BIG

SLIDE 48 Eberhard Wolff - @ewolff Thank You!