Micro Service – The New Architecture Paradigm
- 1. Micro Services – The New
Architecture Paradigm
Eberhard Wolff
Freelancer
Head Technology Advisory Board
adesso AG
http://ewolff.com
- 5. Eberhard Wolff - @ewolff
Common libraries & technical foundation
Order Billing Search Catalog
E Commerce
Shop
Deployment monolith
Global code integration & coordination needed
Code changes to production takes loooong
Architecture can be non-monolithic but dependencies
might sneak in
How to introduce e.g. Elasticsearch for Search?
- 6. Eberhard Wolff - @ewolff
Micro Services: Definition
• Small
• Independent deployment units
• i.e. processes
• Any technology
• Any infrastructure
Micro
Service
Server
Micro
Service
Server
- 7. Eberhard Wolff - @ewolff
Micro Services
• Component Model
• Component…
• Separate process
• Individual deployment unit
• GUI+Logic
- 8. Eberhard Wolff - @ewolff
Micro Services vs. SOA
• Micro Service:
1 service = 1 deployment unit
Service + GUI
• SOA:
1 deloyment unit = n services
Service / GUI separate
- 9. Eberhard Wolff - @ewolff
Components Collaborate
Micro
Service
Micro
Service
Link
Data Replication
REST
Messaging
- 10. Eberhard Wolff - @ewolff
Common libraries & technical foundation
Order Billing Search Catalog
Global code integration & coordination needed
Code changes to production takes loooong
Architecture can be non-monolithic but dependencies
might sneak in
How to introduce e.g. Elasticsearch for Search?
E Commerce
Shop
Deployment monolith
- 11. Eberhard Wolff - @ewolff
Common libraries & technical foundation
Order Billing Search Catalog
Global code integration & coordination needed
Code changes to production takes loooong
Architecture can be non-monolithic but dependencies
might sneak in
How to introduce e.g. Elasticsearch for Search?
Order CatalogSearchBilling
Micro Services
Team can deploy without integration
Changes can be deployed independently & quickly
Technology stack per Micro Service
One or many Micro Services per Team
- 12. Eberhard Wolff - @ewolff
Order Billing Search Catalog
Order CatalogSearchBilling
Micro Services
Team can deploy without integration
Changes can be deployed independently & quickly
Strong & enforced modularization
Technology stack per Micro Service
One or many Micro Services per Team
- 13. Eberhard Wolff - @ewolff
Online Shop
Order
Catalog
Search
Billing
Customer
HTML /
HTTP
- 14. Eberhard Wolff - @ewolff
Online Shop
Elasticsearch
Spring Batch
Oracle
Spring MVC
MongoDB
Order
Catalog
Search
Billing
- 16. Eberhard Wolff - @ewolff
Component Model
• No restriction on language etc
• Individual processes
• + infrastructure (database etc)
• JARs, WARs, EARs: No good fit
• Monitoring
• Logging
- 17. Eberhard Wolff - @ewolff
Possible Component Models
• Virtual machine
• Docker container
• Installable software (RPM, deb)
• + deployment / config scripts
- 20. Eberhard Wolff - @ewolff
Conway‘s Law
Architecture
copies
communication structures
of the organization
- 21. 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
- 22. 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
- 23. Eberhard Wolff - @ewolff
One team can
build and
deploy features
independently!
- 24. Eberhard Wolff - @ewolff
Team must be
responsible for
a sensible set
of functionality
- 25. Eberhard Wolff - @ewolff
Conway’s Law & Size
• Upper limit: What a (small) team
can handle
• …and a meaningful set of features
• Probably not too small
• Smaller modules might be better
• Lower limit: Depends on overhead /
technology
- 31. Eberhard Wolff - @ewolff
HTTP
New
Stuff
Links
No legacy code
Any technology
J
Small code base
- 35. Eberhard Wolff - @ewolff
Monoliths
• Architecture rot
• …not maintainable any more
• …and can’t be rewritten / replaced
- 36. Eberhard Wolff - @ewolff
Micro Services
• Distributed system of small units
• Architecture violations harder
• Small units
• Easy to replace
- 38. Eberhard Wolff - @ewolff
Monolith
ECommerce
System
3rd party
systems
Database
- 39. Eberhard Wolff - @ewolff
Continuous Delivery:
Build Pipeline
Commit
Stage
Automated
Acceptance
Testing
Automated
Capacity
Testing
Manual
Explorative
Testing
Release
ECommerce
System
- 40. Eberhard Wolff - @ewolff
Build Pipeline: Problems
• Complex infrastructure
• Huge database
• 3rd party integration
• Slow feedback
• Test everything for each commit
• Huge deployment unit
• Deployment slow
- 41. Eberhard Wolff - @ewolff
Micro Services
ECommerce
System
3rd party
systems
Database
Order
Catalog
Billing
Search
- 42. Eberhard Wolff - @ewolff
Commit
Stage
Automated
Acceptance
Testing
Automated
Capacity
Testing
Manual
Explorative
Testing
Release
Commit
Stage
Automated
Acceptance
Testing
Automated
Capacity
Testing
Manual
Explorative
Testing
Release
Commit
Stage
Automated
Acceptance
Testing
Automated
Capacity
Testing
Manual
Explorative
Testing
Release
Order
Billing
Customer
- 43. Eberhard Wolff - @ewolff
Build Pipeline for
Micro Services
• Independent deployment
• Build pipeline per Micro Service
• Smaller
• Easier to set up
• Less features (3rd party systems)
• Faster Feedback: Less tests
- 44. Eberhard Wolff - @ewolff
Quick Deployments
Time
Size & Risk
Manual
Deployment
Pipeline
Continuous
Delivery
Pipeline
Monolith
Micro Services
- 45. Eberhard Wolff - @ewolff
Why Micro Services?
• Strong modularization
• Small deployment units
• Faster & easier deployment
• Sustainable development speed
• Continuous Delivery
• Less risk in deployment
• Best technology for each service
- 48. Eberhard Wolff - @ewolff
1st Law of Distributed Objects
• Don’t Distribute Your Objects!
• Too much remote communication &
overhead
• Lesson learned from CORBA etc
• Micro Service should include a GUI
• http://martinfowler.com/bliki/
FirstLaw.html
- 49. Eberhard Wolff - @ewolff
Request
Response
Processing
Latency Round Trip:
0,2-0,5 ms
= 600.000-1.500.000
instructions@3GHz
- 50. Eberhard Wolff - @ewolff
1st Law of Distributed Objects &
Micro Services
• Small Micro Services mean a lot of
communication
• Violate the 1st Law
• Seems to work, though
• http://martinfowler.com/articles/
distributed-objects-
microservices.html
- 52. Eberhard Wolff - @ewolff
Code Reuse
• Reuse across technology stacks hard
• Code dependencies are evil!
• Deployment dependency
• No more independent deployment
• Update hell
• Avoid code reuse!
• Or make it Open Source projects (Netflix)
• Service reuse is fine
- 53. Eberhard Wolff - @ewolff
Global Refactorings?
• Move code from service to service
• Might be a port to a different
language
• Separate in a new service?
• More services = more complex
• Very hard
- 54. Eberhard Wolff - @ewolff
Functional Architecture
• Teams should be independent
• i.e. one team = one functionality
• Otherwise: Coordination hard
• Functional architecture much more
important
- 55. Eberhard Wolff - @ewolff
Refactoring &
Code Reuse
Individual
Technology Stacks
- 56. Eberhard Wolff - @ewolff
Refactoring hard
Functional
architecture much
more important
- 57. Eberhard Wolff - @ewolff
Need to get
architecture
right first time
Architecture
evolves
- 58. Eberhard Wolff - @ewolff
Start BIG
• Won’t have too much code at the
start anyway
• Refactoring easier
• Can build architecture as you go
• Let the functional architecture
grow!
- 59. Eberhard Wolff - @ewolff
Handling Interfaces
• Independent deployments =
backwards compatibility
• Different versions of the same service
run at the same time
• Only to allow updates
• i.e. transient
• Minor issue
- 60. Eberhard Wolff - @ewolff
Managing Dependencies
Between (>100) Services?
• Monoliths can be easily analyzed
• Micro Services?
• With heterogeneous technology
stacks?
• Need to come up with your own
solution
- 61. Eberhard Wolff - @ewolff
Global Architecture?
• Manages dependencies
• Which service/team does what?
• Defines common communication
infrastructure
• Optional: Common Ops
• Very different from usual architecture
- 62. Eberhard Wolff - @ewolff
Network?
• Micro Services = Distributed Systems
• Services & network might fail
• Need to deal with failure
• Resilience: System must survive
failure of parts
• Makes system highly available
- 63. Eberhard Wolff - @ewolff
Deployment?
• One Deployment Pipeline per
services
• Should be fully automated
• Too many services for manual steps
• Infrastructure investment needed
• Common deployment?
- 64. Eberhard Wolff - @ewolff
Infrastructure?
• >50 server per system
• Resource consumption probably
high
• Virtualization must be fully
automated
• Docker might save ressources
- 66. Eberhard Wolff - @ewolff
Conclusion: Micro Services
• Micro Services are a new way of
modularization
• More technological freedom
• Easier, faster and less risky
deployment
- 67. Eberhard Wolff - @ewolff
Use If…
• Time to market is important
• Legacy systems must be
modernized
• Sustained development speed
• Continuous Delivery should be
implemented
• Large enough project
- 68. Eberhard Wolff - @ewolff
Don’t Use If…
• Infrastructure complexity cannot be
handled
• Architectural complexity cannot be
handled