Micro Services

Micro Services
Smaller is Better?
Eberhard Wolff
Freelance consultant & trainer
http://ewolff.com
Who has seen
a system that
was too
large?
Eberhard Wolff - @ewolff
Who has seen
a system that
was too
small?
Eberhard Wolff - @ewolff
Little programs are
delightful to write in
isolation,
but the process of
maintaining large-scale
software is always
miserable.
Jaron Lanier
Micro Services: Definition
•  Small
•  Independent deployment units
•  i.e. processes
Micro
Micro
Service Service
•  Any technology
•  Any infrastructure Server
Server
Eberhard Wolff - @ewolff
Components Collaborate
Link
Micro
Service
REST
Micro
Service
Messaging
Data Replication
Eberhard Wolff - @ewolff
Why Micro Services?
Strong
modularization
Replaceability
Small units
Sustainable
Development
speed
Continuous
Delivery
Deployment
less risky
Free Choice of
technology
Eberhard Wolff - @ewolff
Micro Service
=
Micro?
Eberhard Wolff - @ewolff
Smaller modules
better
10-100LOC
http://yobriefca.se/blog/
2013/04/28/micro-service-architecture/
Eberhard Wolff - @ewolff
Smaller modules
better
10-100LOC
http://yobriefca.se/blog/
2013/04/28/micro-service-architecture/
Eberhard Wolff - @ewolff
Game of
Life
Eberhard Wolff - @ewolff
Game of Life in one line of APL
life←{ ⍝ John Conway's "Game of Life".
↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵
⍝ Expression for next generation.
}
LOC is really a bad metric
dyalog.com
Eberhard Wolff - @ewolff
Larger?
•  Micro Services have an overhead
•  Build & deployment pipeline
•  Version control
Eberhard Wolff - @ewolff
st
1
Law of Distributed Objects
•  Don’t Distribute Your Objects!
•  Too much remote communication &
overhead
•  Lesson learned from CORBA etc
•  http://martinfowler.com/bliki/
FirstLaw.html
Eberhard Wolff - @ewolff
Request
Latency Round Trip:
0,2-0,5 ms
= 600.000-1.500.000
instructions@3GHz
Processing
Response
Eberhard Wolff - @ewolff
st
1
Law of Distributed Objects &
Micro Services
•  Small Micro Services =
lot of communication
•  Violates the 1st Law
•  Seems to work, though
•  http://martinfowler.com/articles/
distributed-objectsmicroservices.html
Eberhard Wolff - @ewolff
Too small =
too much
communication
Eberhard Wolff - @ewolff
L
Eberhard Wolff - @ewolff
Again:
Why Micro
Services?
Eberhard Wolff - @ewolff
The main
reason
Eberhard Wolff - @ewolff
Business
relevant
Eberhard Wolff - @ewolff
How to scale
agile?
Implement
more feature
Eberhard Wolff - @ewolff
Conways Law
Architecture
copies
communication structures
of the organization
Eberhard Wolff - @ewolff
Conway’s Law as a Limit
•  Won’t be able to create an
architecture different from your
organization
•  I.e. mobile, GUI & database team
•  Three technical artifacts
Eberhard Wolff - @ewolff
Conway’s Law as an Enabler
•  Desired architecture =
project structure
•  Team for each Micro Service
•  Team should be responsible for
meaningful features
•  Ideal: Independent features
Eberhard Wolff - @ewolff
Each team can
build and
deploy features
independently!
Eberhard Wolff - @ewolff
Micro Services
must provide a
sensible set of
functionality
Eberhard Wolff - @ewolff
Conway’s Law &
Micro Service 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
Eberhard Wolff - @ewolff
Micro Service = Micro?
•  Size doesn’t matter too much
•  Teams must be able to work
independently
•  Small enough for one team
•  Not too much overhead
Eberhard Wolff - @ewolff
Conway’s Law
Product
Owner
Feature
Service
Service
Eberhard Wolff - @ewolff
Bad
architecture?
Still can’t be
avoided!
Eberhard Wolff - @ewolff
Conway’s Law
Product
Owner
Priority?
Product
Owner
Feature
Communication
Service
Slow
Service
Eberhard Wolff - @ewolff
Conway’s Law
•  Software Interface =
Team Communication
•  Too much communication if you get
the architecture wrong.
•  Slows down the process
Eberhard Wolff - @ewolff
Collective
Code
Ownership
Conway’s Law
Product
Owner
Review
Pull Request
Service
Product
Owner
Feature
Change
Service
Eberhard Wolff - @ewolff
Micro Service &
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
Eberhard Wolff - @ewolff
Micro Service &
Collective Code Ownership
•  Team must understand bigger parts
of the code
•  Technology freedom?
Eberhard Wolff - @ewolff
Refactoring
Refactoring
Service
Service
Different libraries
Different language
Possibly a rewrite
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
Eberhard Wolff - @ewolff
Refactoring
Service
Service
Library
Releases must be coordinated
…and we want independent releases
Enforces same language / platform
Hard to implement really reusable code
Like: really, really hard Eberhard Wolff - @ewolff
Refactoring
Service
Service
Service
Remote communication
Slower calls
Unreliable network
Not great
But best option
Eberhard Wolff - @ewolff
Number of
Services
will
increase
Refactoring
across
Services
hard
Start BIG
•  Conway’s law: Upper size =
what a team can handle
•  Refactoring inside a service easier
•  …needed for agile environments
•  …where Micro Services are used
•  Number will increase anyway
•  Tear apart easier than join
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
Eberhard Wolff - @ewolff
Systems can
not be
engineered
Systems
grow.
Guide
growth.
Sum Up
Conway’s Law
Collective Code
Ownership
or
Micro Services
Start
BIG
Faster Time-toMarket
Refactoring
Eberhard Wolff - @ewolff
Leseprobe:
http://bit.ly/CD-Buch
Eberhard Wolff - @ewolff
Leading Micro Services
Conference
http://microxchg.io/
Berlin, 2015-2-12/13
Eberhard Wolff - @ewolff
Thank You!
Eberhard Wolff - @ewolff