micro services - smaller is better?
Post on 14-Jul-2015
2.007 Views
Preview:
TRANSCRIPT
Micro Services Smaller is Better?
Eberhard Wolff Freelance consultant & trainer
http://ewolff.com
Eberhard Wolff - @ewolff
Who has seen a system that
was too large?
Eberhard Wolff - @ewolff
Who has seen a system that
was too small?
Little programs are delightful to write in
isolation, but the process of
maintaining large-scale software is always
miserable.
Jaron Lanier
Eberhard Wolff - @ewolff
Micro Services: Definition • Small • Independent deployment units • i.e. processes
• Any technology • Any infrastructure
Micro Service
Server
Micro Service
Server
Eberhard Wolff - @ewolff
Components Collaborate
Micro Service
Micro Service
Link
Data Replication
REST Messaging
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
10-100LOChttp://yobriefca.se/blog/ 2013/04/28/micro-service-architecture/
Smaller modules better
Eberhard Wolff - @ewolff
10-100LOChttp://yobriefca.se/blog/ 2013/04/28/micro-service-architecture/
Smaller modules better
Eberhard Wolff - @ewolff
Game of Life
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
Eberhard Wolff - @ewolff
Larger? • Micro Services have an overhead
• Build & deployment pipeline
• Version control
Eberhard Wolff - @ewolff
1st 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
Response
Processing
Latency Round Trip: 0,2-0,5 ms = 600.000-1.500.000 instructions@3GHz
Eberhard Wolff - @ewolff
1st 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-objects-microservices.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
Service
Feature
Service
Eberhard Wolff - @ewolff
Bad architecture?
Still can’t be avoided!
Eberhard Wolff - @ewolff
Conway’s Law Product Owner
Service Service
Feature Product Owner
Communication
Priority?
Slow
Eberhard Wolff - @ewolff
Conway’s Law • Software Interface =
Team Communication • Too much communication if you get
the architecture wrong.
• Slows down the process
Collective Code
Ownership
Eberhard Wolff - @ewolff
Conway’s Law Product Owner
Service Service
Feature Product Owner
Change
Review Pull Request
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?
Refactoring
Eberhard Wolff - @ewolff
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
Hard to implement really reusable code Enforces same language / platform
Like: really, really hard
…and we want independent releases
Eberhard Wolff - @ewolff
Refactoring
Service Service
Service Remote communication
Unreliable network Slower calls
Not great But best option
Number of Services
will increase
Refactoring across
Services hard
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 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
Systems can not be
engineered
Systems grow.
Guide growth.
Sum Up
Eberhard Wolff - @ewolff
Faster Time-to-Market
Micro Services Refactoring
Conway’s Law Collective Code Ownership
Start BIG
or
Eberhard Wolff - @ewolff
Leseprobe: http://bit.ly/CD-Buch
Eberhard Wolff - @ewolff
Leading Micro Services Conference
Berlin, 2015-2-12/13 http://microxchg.io/
Eberhard Wolff - @ewolff
Thank You!
top related