Upgrade to Pro — share decks privately, control downloads, hide ads and more …

You don't want no microservices!

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).

E698a765c9d04ae52d5e1815b2007cfe?s=128

Uwe Friedrichsen

November 03, 2020
Tweet

Transcript

  1. You don’t want no microservices! A down-to-earth evaluation of microservices

    Uwe Friedrichsen – codecentric AG – 2016-2020
  2. Uwe Friedrichsen CTO @ codecentric https://twitter.com/ufried https://www.speakerdeck.com/ufried https://ufried.com/blog/microservices_fallacy_1

  3. Microservices – A clarification

  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
  5. The microservices fashion

  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!
  7. How it all started

  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
  9. The fallacies

  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
  11. Scalability

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

    reasons
  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
  14. With 15 LAMP stack servers you could handle entire Germany

    * * everybody from “toddler to dodderer”
  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%
  16. Simplicity

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

    monolithic application …
  18. … but the essential complexity of the solution does not

    magically disappear
  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.)
  20. Structural complexity with microservices means remote communication …

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

    of distributed systems
  22. Everything fails, all the time. -- Werner Vogels

  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
  24. Yet, we usually use deterministic thinking to reason about distributed

    systems
  25. Failures in distributed systems ... • Crash failure • Omission

    failure • Timing failure • Response failure • Byzantine failure
  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 • ...
  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"
  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
  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 • …
  30. Microservices increase the overall solution complexity by at least an

    order of magnitude
  31. Reusability

  32. The typical reusability reasoning IT person to business sponsor: “We

    definitely need to invest in implementing <cool new architectural paradigm>. I know this does not create any business value now, but it allows us to create reusable <architectural paradigm building blocks>! 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!
  33. Reusability rarely pays! Creating a reusable asset is a lot

    harder and costs a lot more than most people think
  34. The tar pit by Frederick P. Brooks, Jr. (taken from

    the “The mythical man-month”) [Bro 1995]
  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
  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
  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
  38. Designing for reusable microservices means deliberately crippling availability

  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
  40. The value of reuse unfolds inside a process boundary Across

    process boundaries it should be avoided as it maximizes coupling
  41. Autonomy

  42. Autonomy with respect to what?

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

    level
  44. Microservices can support autonomy, but only if you have set

    up your organization and processes for autonomous decision making
  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
  46. Better design

  47. “Microservices lead to better application design. Monoliths always turn into

    big balls of mud. With microservices this does not happen.”
  48. The chosen runtime structure does not impede your source code

    structure by any means.
  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.
  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
  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
  52. If you are not willing to work on these things

    first, most likely you will end up with a distributed ball of mud
  53. Easier change of technology

  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)
  55. Why are we so obsessed with technology updates? In practice

    they are by far the rarest kind of change requirement
  56. Because if we need to update technology, it tends to

    be very painful
  57. Why are technology updates painful?

  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
  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.
  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
  61. Actual reasons • Moving fast • Very disparate NFRs

  62. Moving fast

  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
  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
  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.
  66. Very disparate NFRs

  67. With a monolith, the monolith needs to implement the union

    of all runtime related NFRs
  68. This can become tedious if you have very disparate NFRs

    that affect only parts of your application
  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
  70. Microservices are a possible way of splitting up the monolith

    but not the only one
  71. Actual reasons • Moving fast • Very disparate NFRs Still,

    not the only option available to implement it
  72. Making sense of it all

  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?
  74. Well, it depends …

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

    competitive market?
  76. Need to move fast? Y

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

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

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

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

    N
  81. Do you have very disparate NFRs or other constraints that

    require you to split up your application at runtime?
  82. Need to move fast? Very disparate NFRs? Multiple teams? Microservices

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

    Microservices Y N Y Y N
  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
  85. Need to move fast? Very disparate NFRs? Multiple teams? Modulith

    Microlith Microservices Y N Y Y N N
  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
  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
  88. General recommendations

  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
  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
  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
  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”
  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
  94. Wrap-up

  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
  96. Uwe Friedrichsen CTO @ codecentric https://twitter.com/ufried https://www.speakerdeck.com/ufried https://ufried.com/blog/microservices_fallacy_1