You don't want no microservices!

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Microservices – A clarification

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

The microservices fashion

Slide 6

Slide 6 text

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!

Slide 7

Slide 7 text

How it all started

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

The fallacies

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Scalability

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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%

Slide 16

Slide 16 text

Simplicity

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Structural complexity with microservices means remote communication …

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Everything fails, all the time. -- Werner Vogels

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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 • …

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Reusability

Slide 32

Slide 32 text

The typical reusability reasoning IT person to business sponsor: “We definitely need to invest in implementing . 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!

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Designing for reusable microservices means deliberately crippling availability

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Autonomy

Slide 42

Slide 42 text

Autonomy with respect to what?

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Better design

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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.

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

Easier change of technology

Slide 54

Slide 54 text

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)

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

Why are technology updates painful?

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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.

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Actual reasons • Moving fast • Very disparate NFRs

Slide 62

Slide 62 text

Moving fast

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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.

Slide 66

Slide 66 text

Very disparate NFRs

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

Making sense of it all

Slide 73

Slide 73 text

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?

Slide 74

Slide 74 text

Well, it depends …

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

Need to move fast? Y

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

Need to move fast? Multiple teams? Y Y

Slide 79

Slide 79 text

Need to move fast? Multiple teams? Microservices Y Y

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

General recommendations

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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”

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

Wrap-up

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

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