The document discusses microservices as a new software architecture paradigm. It defines microservices as small, independent processes that work together to form an application. The key benefits of microservices are that they allow for easier, faster deployment of features since each service is its own deployment unit and teams can deploy independently without integration. However, the document also notes challenges of microservices such as increased communication overhead, difficulty of code reuse across services, and managing dependencies between many different services. It concludes that microservices are best for projects where time to market is important and continuous delivery is a priority.

1. Micro Services – The New
Architecture Paradigm
Eberhard Wolff
Freelancer
Head Technology Advisory Board
adesso AG
http://ewolff.com

2. Eberhard Wolff - @ewolff
Leseprobe:
http://bit.ly/CD-Buch

3. Eberhard Wolff - @ewolff
GUI
Logic
DB
E Commerce
Shop
Change
Order
Process!

4. Eberhard Wolff - @ewolff
Thou shalt not
organize
teams by
technology!

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

15. Eberhard Wolff - @ewolff
Deploy &
Operate?

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

18. Eberhard Wolff - @ewolff
Why Micro
Services?

19. Eberhard Wolff - @ewolff
How to scale
agile?
Implement
more feature

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

26. Eberhard Wolff - @ewolff
Legacy Apps

27. Eberhard Wolff - @ewolff

28. Eberhard Wolff - @ewolff

29. Eberhard Wolff - @ewolff
How can I
implement a
new feature???

30. Eberhard Wolff - @ewolffL

31. Eberhard Wolff - @ewolff
HTTP
New
Stuff
Links
No legacy code
Any technology
J
Small code base

32. Little programs are
delightful to write in
isolation,
but the process of
maintaining large-scale
software is always
miserable.
Jaron Lanier

33. Friedenspreis
des deutschen
Buchhandels

34. Eberhard Wolff - @ewolff
Sustainable
Development

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

37. Eberhard Wolff - @ewolff
Continuous
Delivery

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

46. Eberhard Wolff - @ewolff
Challenges

47. Eberhard Wolff - @ewolff
Distributed
System

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

51. Eberhard Wolff - @ewolff
Too small =
too much
communication

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

65. Eberhard Wolff - @ewolff
Conclusion

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

69. Eberhard Wolff - @ewolff
Thank You!