You don't want no microservices!

This slide deck discusses several widespread fallacies in the context of microservices.

It starts with a little motivation and discussion of the origins of the microservices fashion. Then it discusses and debunks some of the most widespread fallacies that are typically used to justify the use of microservices. After that it looks at the (few) actual reasons that justify the use of microservices.

With that in mind a tiny decision framework is created that one can use to figure out if one needs to look at microservices or if there are better alternatives and how they look like. Finally, a few general recommendations are given that are typically useful in areas where microservices are discussed.

This is the unabridged slide deck containing all slides of the talk. For conferences, I usually leave out several slides to meet the session length constraints.

I also accompany this slide deck with a blog series that can be found at https://ufried.com/blog/microservices_fallacy_1/ (the first post of the series will be published at 6th of November 2020 and the subsequent posts will follow in a weekly rhythm).

Transcript

1. You don’t want no microservices!
   A down-to-earth evaluation of microservices
   Uwe Friedrichsen – codecentric AG – 2016-2020
   

   View Slide

2. Uwe Friedrichsen
   CTO @ codecentric
   https://twitter.com/ufried
   https://www.speakerdeck.com/ufried
   https://ufried.com/blog/microservices_fallacy_1
   

   View Slide

3. Microservices – A clarification
   

   View Slide

4. Microservices
   1. Componentization via services
   2. Organized around business capabilities
   3. Products not projects
   4. Smart endpoints and dumb pipes
   5. Decentralized governance
   6. Decentralized data management
   7. Infrastructure automation
   8. Design for failure
   9. Evolutionary design
   J. Lewis, M. Fowler, https://www.martinfowler.com/articles/microservices.html
   

   View Slide

5. The microservices fashion
   

   View Slide

6. Microservices are it!
   It is how modern IT systems are built!
   Microservices reduce complexity!
   Microservices are needed for scalability!
   Everybody does Microservices!
   We want them!
   We need them!
   

   View Slide

7. How it all started
   

   View Slide

8. How it all started
   • Hyperscalers facing unique problems
   • Figuring out microservices as a solution for them
   • Started talking about it (not neglecting the trade-offs)
   • Enterprise people listening with their specific problems
   • Only noticed the perceived benefits, not the trade-offs
   à The hype started
   

   View Slide

9. The fallacies
   

   View Slide

10. The fallacies
    • Microservices are needed for scalability
    • Microservices are simpler than monoliths
    • Microservices improve reusability
    (and thus pay for themselves)
    • Microservices improve team autonomy
    • Microservices lead to better design
    • Microservices make change of technology easier
    

    View Slide

11. Scalability
    

    View Slide

12. 99,9% of all companies do not need
    microservices for scalability reasons
    

    View Slide

13. Let’s do the math
    • LAMP stack server handles 6.000 concurrent requests *
    • 200 ms to complete incoming request (99 percentile)
    • User sends request approximately every 10 s
    • 300.000 concurrent user sessions (6.000 * (10 s / 200 ms))
    • Max. 5% of user base active at the same time
    • 6.000.000 users can be served with a single LAMP server
    • Easily scalable to multiple servers with a load balancer
    * If configured properly, probably more if you use nginx instead of Apache Web Server
    

    View Slide

14. With 15 LAMP stack servers
    you could handle entire Germany *
    * everybody from “toddler to dodderer”
    

    View Slide

15. You do not need microservices
    to handle your scalability needs
    unless you are a hyperscaler, online ad broker or someone else of the 0,1%
    

    View Slide

16. Simplicity
    

    View Slide

17. A single microservice is easier to understand
    than a big, monolithic application …
    

    View Slide

18. … but the essential complexity of the solution
    does not magically disappear
    

    View Slide

19. Principle of conservation of essential complexity
    The amount of essential complexity that
    a solution needs to implement is constant.
    (If you simplify the building blocks, the structure becomes more complex and vice versa.)
    

    View Slide

20. Structural complexity with microservices
    means remote communication …
    

    View Slide

21. … i.e., you are confronted with all intricacies
    and imponderabilities of distributed systems
    

    View Slide

22. Everything fails, all the time.
    -- Werner Vogels
    

    View Slide

23. If X then Y
    What we learned in our IT education
    If X then maybe Y
    This changes
    everything!
    What we need for distributed systems
    We are good at this (due to how our brains work)
    Inside process thinking
    Reasoning about
    deterministic behavior
    Designing a complicated system
    We are poor at that (due to how our brains work)
    Reasoning about
    non-deterministic behavior
    Across process thinking
    Designing a complex system
    

    View Slide

24. Yet, we usually use deterministic thinking
    to reason about distributed systems
    

    View Slide

25. Failures in distributed systems ...
    • Crash failure
    • Omission failure
    • Timing failure
    • Response failure
    • Byzantine failure
    

    View Slide

26. ... lead to a variety of effects …
    • Lost messages
    • Incomplete messages
    • Duplicate messages
    • Distorted messages
    • Delayed messages
    • Out-of-order message arrival
    • Partial, out-of-sync local memory
    • ...
    

    View Slide

27. ... turning seemingly simple issues into very hard ones
    Time & Ordering
    Leslie Lamport
    "Time, clocks, and the
    ordering of events in
    distributed systems"
    Consensus
    Leslie Lamport
    ”The part-time
    parliament”
    (Paxos)
    CAP
    Eric A. Brewer
    "Towards robust
    distributed systems"
    Faulty processes
    Leslie Lamport,
    Robert Shostak,
    Marshall Pease
    "The Byzantine
    generals problem"
    Consensus
    Michael J. Fischer,
    Nancy A. Lynch,
    Michael S. Paterson
    "Impossibility of
    distributed consensus
    with one faulty
    process” (FLP)
    Impossibility
    Nancy A. Lynch
    ”A hundred
    impossibility proofs
    for distributed
    computing"
    

    View Slide

28. Effects of distributed systems
    • Distributed systems introduce non-determinism regarding
    • Execution completeness
    • Message ordering
    • Communication timing
    • You will be affected by this at the application level
    • Don’t expect your infrastructure to hide all effects from you
    • Better have a plan to detect and recover from inconsistencies
    

    View Slide

29. Microservices require ...
    • Very different design technique
    • Much more implementation rigor
    • Reliable error detection and handling at the application level
    • Complex monitoring and observability support
    • Significant infrastructure upgrade
    • …
    

    View Slide

30. Microservices increase the overall solution complexity
    by at least an order of magnitude
    

    View Slide

31. Reusability
    

    View Slide

32. The typical reusability reasoning
    IT person to business sponsor:
    “We definitely need to invest in implementing architectural paradigm>. I know this does not create any
    business value now, but it allows us to create reusable
    !
    This way, we will have to pay a lot less for future projects,
    they will be a lot faster and we will be a lot more flexible.
    In short: the investment will pay for itself very soon.”
    Never worked this way, never will work!
    

    View Slide

33. Reusability rarely pays!
    Creating a reusable asset is a lot harder and costs a lot more than most people think
    

    View Slide

34. The tar pit
    by Frederick P. Brooks, Jr.
    (taken from the “The mythical man-month”)
    [Bro 1995]
    

    View Slide

35. 1x
    Program
    The original module,
    suitable for the context
    it was created for
    3x
    Programming
    Product
    A generalized module,
    suitable for multiple
    contexts
    A module, ready to be
    used in an ecosystem
    of interacting modules
    A (re-)usable module,
    that provides a general
    solution for a problem
    3x
    Programming
    System
    9x
    Programming
    Systems
    Product
    

    View Slide

36. 1x
    Program
    9x
    Programming
    Systems
    Product
    Completeness of functionality
    • Handling of edge cases
    • Hardening implementation
    • Thorough functional testing
    • Design Documentation
    Completeness of accessibility
    • Precise interface definition
    • Clear behavioral contract
    • Thorough integration (or alike) testing
    • API Documentation
    

    View Slide

37. The coupling dilemma
    • Reusability is tightest form of coupling possible
    • If a reused service fails, reusing services fail, too
    • Availability requires avoiding cascading failures
    • If a service fails, the failure must not spread to other services
    • Reusability means cascading failures by definition
    • Due to the tight coupling between reused and reusing service
    • Technical measures cannot avoid it
    • The tight coupling is on the functional level
    

    View Slide

38. Designing for reusable microservices
    means deliberately crippling availability
    

    View Slide

39. Dismiss reusability in service design
    • Reusability maximizes coupling
    • Reusability leads to bad service design (vertical decomposition)
    • Reusability compromises availability and increases latency
    • Reusability rarely pays
    • Remember Fred Brook’s “Rule of 9”
    • The things worth being made reusable usually already exist
    • Do not strive for reuse, strive for replaceability instead
    • Additionally aim for functional independence and autonomy
    • Try to tackle reusability issues with libraries
    

    View Slide

40. The value of reuse unfolds inside a process boundary
    Across process boundaries it should be avoided as it maximizes coupling
    

    View Slide

41. Autonomy
    

    View Slide

42. Autonomy with respect to what?
    

    View Slide

43. Autonomy starts on an organizational level,
    not on a technical level
    

    View Slide

44. Microservices can support autonomy,
    but only if you have set up your organization and processes
    for autonomous decision making
    

    View Slide

45. Otherwise, microservices only increase complexity *
    * what they do in most companies as they shirk to establish an organization set up for decentralized decision making
    

    View Slide

46. Better design
    

    View Slide

47. “Microservices lead to better application design.
    Monoliths always turn into big balls of mud.
    With microservices this does not happen.”
    

    View Slide

48. The chosen runtime structure does not impede
    your source code structure by any means.
    

    View Slide

49. A deployment monolith can be perfectly structured.
    If it is not, it is due to a lack of knowledge, experience and discipline – plus an impeding environment.
    

    View Slide

50. If teams find it hard to create a well structured monolith,
    I don't rate their chances of creating
    a well structured microservices architecture.
    -- Simon Brown
    http://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html
    

    View Slide

51. For better design, work on …
    • Better functional design skills
    • Crucial especially in distributed system design
    • An environment understanding the needs of software better
    • Just pushing for features becomes very expensive over time
    • Better essential documentation
    • For helping the person coming after you to pick things up
    • Education and discipline
    • To not accidentally or deliberately violating the design
    

    View Slide

52. If you are not willing to work on these things first,
    most likely you will end up with a distributed ball of mud
    

    View Slide

53. Easier change of technology
    

    View Slide

54. Easier change of technology
    • Partially true
    • Technology migration scenarios easier to execute
    • Supports easier exploration of alternative technologies
    • Yet, overall migration efforts remain the same
    • Usually, biggest effort driver is missing functional knowledge
    • Units of migration are smaller (good for risk management)
    

    View Slide

55. Why are we so obsessed with technology updates?
    In practice they are by far the rarest kind of change requirement
    

    View Slide

56. Because if we need to update technology,
    it tends to be very painful
    

    View Slide

57. Why are technology updates painful?
    

    View Slide

58. Technology updates are painful …
    • Due to broken IT governance processes
    • Not a technology issue
    • Microservices do not solve the problem
    • Due to application dependencies on the OS level
    • Solved by containers
    • Containers are not limited to microservices
    

    View Slide

59. If you face a non-technical problem, tackle the root cause.
    Do not try to evade it with a technical patch.
    This will make the problem worse, not better.
    

    View Slide

60. The fallacies
    • Microservices are needed for scalability
    • Microservices are simpler than monoliths
    • Microservices improve reusability
    (and thus pay for themselves)
    • Microservices improve team autonomy
    • Microservices lead to better design
    • Microservices make change of technology easier
    

    View Slide

61. Actual reasons
    • Moving fast
    • Very disparate NFRs
    

    View Slide

62. Moving fast
    

    View Slide

63. Most important reason to pick up microservices:
    The need to move fast in a highly competitive market *
    * That was the core challenge of the hyperscalers, most of them living in a “winner takes all” market
    

    View Slide

64. Moving fast with the market
    • Align organization with market capabilities
    • Build cross-functional teams
    • Decentralize decision authority
    • Minimize need for coordination and lock-step activities
    • Support team autonomy on the IT level
    • Make sure IT artifacts do not cross team boundaries
    • Make sure teams can deploy independently
    • Microservices are a way of achieving these properties
    

    View Slide

65. Do you need to move fast in a highly competitive market?
    Are you willing to rebuild your organization and processes?
    If the answer to one of the two questions is “No”, you probably do not need microservices.
    

    View Slide

66. Very disparate NFRs
    

    View Slide

67. With a monolith, the monolith needs to implement
    the union of all runtime related NFRs
    

    View Slide

68. This can become tedious if you have very disparate NFRs
    that affect only parts of your application
    

    View Slide

69. In such a setting it can be better to split up
    your monolith in several parts,
    each part only implementing the NFRs
    that are required for it
    

    View Slide

70. Microservices are a possible way of splitting up the monolith
    but not the only one
    

    View Slide

71. Actual reasons
    • Moving fast
    • Very disparate NFRs
    Still, not the only option available to implement it
    

    View Slide

72. Making sense of it all
    

    View Slide

73. Okay, got it. But I still do not have a clear answer:
    Should I use microservices or not?
    And if not, what should I do instead?
    

    View Slide

74. Well, it depends …
    

    View Slide

75. Do you really need to move fast in a highly competitive market?
    

    View Slide

76. Need to
    move fast?
    Y
    

    View Slide

77. Do you need to move fast at scale, i.e., with multiple teams?
    

    View Slide

78. Need to
    move fast?
    Multiple
    teams?
    Y
    Y
    

    View Slide

79. Need to
    move fast?
    Multiple
    teams?
    Microservices
    Y
    Y
    

    View Slide

80. Need to
    move fast?
    Multiple
    teams?
    Microservices
    Y
    N
    Y
    N
    

    View Slide

81. Do you have very disparate NFRs or other constraints
    that require you to split up your application at runtime?
    

    View Slide

82. Need to
    move fast?
    Very
    disparate
    NFRs?
    Multiple
    teams?
    Microservices
    Y
    N
    Y
    Y
    N
    

    View Slide

83. Need to
    move fast?
    Very
    disparate
    NFRs?
    Multiple
    teams?
    Microlith
    Microservices
    Y
    N
    Y
    Y
    N
    

    View Slide

84. Microlith
    • Service-based design (independent runtime units)
    • Services must not call other services
    while processing external requests
    • State synchronization temporally decoupled
    from request processing
    • Via event push or state update pull
    • Very different runtime properties from microservices
    • Intricacies of distributed systems significantly mitigated
    

    View Slide

85. Need to
    move fast?
    Very
    disparate
    NFRs?
    Multiple
    teams?
    Modulith
    Microlith
    Microservices
    Y
    N
    Y
    Y
    N
    N
    

    View Slide

86. Modulith
    • Well-structured deployment monolith (single runtime unit)
    • Built from strictly decoupled modules
    • Communication between modules only via APIs
    • Modularization can be extended to data store and UI
    • Supports team autonomy
    • Requires good design and adherence to rules
    • Simple to handle at runtime
    

    View Slide

87. Need to
    move fast?
    Very
    disparate
    NFRs?
    Multiple
    teams?
    Modulith
    Microlith
    Microservices
    But I always
    end up with a
    big ball of mud
    Learn better
    design and to
    adhere to it
    But I want to go
    with the fashion
    But the runtime
    intricacies are
    killing me
    Y
    N
    Y
    Y
    N
    N
    

    View Slide

88. General recommendations
    

    View Slide

89. Learn better functional design
    • Good functional design supports
    • understandability, changeability, evolvability, portability,
    availability, performance, team autonomy, …
    • Unsolved issue for 50+ years
    • DDD points in the right direction, yet no panacea
    • Would solve 99% of the problems,
    people hope microservices would solve
    

    View Slide

90. Do better architectural work
    • Understand the problem from all perspectives
    • Find alternative solution options
    • Evaluate the trade-offs
    • Help stakeholders make best decisions possible
    

    View Slide

91. Improve requirements engineering
    • Need to understand demands and consequences
    • Impeded by widespread division-of-labor approach
    • Help find requirements that do not harm the design
    • Often, alternatives with same outcome are possible
    • If not, you need to change the design of course
    • Uncover the actual “needs” behind the “wants”
    • Helps to avoid lots of accidental complexity
    

    View Slide

92. Help people understand software
    • Not comparable to physical goods
    • Needs to be changed after initial release to keep its value
    • Software development is design, not shop floor assembly
    • Extreme malleability of software can turn into a curse
    • Invisibility makes it very hard to grasp “software”
    

    View Slide

93. Simplify!
    • IT drowns in ever-growing complexity
    • IT becomes indispensable in business and private lives
    • Extremely dangerous combination, poised to crash
    • Need to avoid piling up more accidental complexity
    • Microservices often are accidental complexity
    

    View Slide

94. Wrap-up
    

    View Slide

95. Wrap-up
    • Microservices are a fashion
    • Often used because „one does it“
    • Many fallacies to justify use of microservices
    • Scalability, simplicity, reusability, autonomy, better design, …
    • Usually only valuable if you need to go fast at scale
    • High price for using microservices
    • Simpler options available, e.g., microliths and moduliths
    • Learn good modularization and functional design
    

    View Slide

96. Uwe Friedrichsen
    CTO @ codecentric
    https://twitter.com/ufried
    https://www.speakerdeck.com/ufried
    https://ufried.com/blog/microservices_fallacy_1
    

    View Slide