Microservices: A retrospective

Slide 1

Slide 1 text

Microservices: A Retrospective Tomer Gabel @ Reversim Summit, 2019

Slide 2

Slide 2 text

Agenda 1. Why oh why 2. Lessons learned 3. Lessons not learned 4. The big reveal Image: Today's Menu by Hypnotica Studios Infinite via Flickr (CC BY 2.0)

Slide 3

Slide 3 text

Technology malcontent Who am I? Engineer @ Organizer Reversim Summit alumnus x7

Slide 4

Slide 4 text

1. WHY OH WHY Image: 40+216 Faces by bark via Flickr (CC BY 2.0)

Slide 5

Slide 5 text

Why do Microservices? • Developer velocity – Independent releases – Limited scope of work – Stronger decoupling • All thanks to bounded context Image: Playing on the Merry go round by Charles Knowles via Flickr (CC BY 2.0)

Slide 6

Slide 6 text

Why do Microservices? • Scalability – Independent scaling – Independent storage – Limited scope is easier to optimize • All thanks to bounded context Image: Skyscraper Under Clear Day Sky via Pixabay (Pixels license)

Slide 7

Slide 7 text

• Resilience – Strict error boundaries – Partial failures • Secondary benefits – Polyglot – Easier to test (maybe?) • Yup: also thanks to bounded context Why do Microservices? Image: Building collapse in Łódź, Sienkiewicza & Tuwima Streets, November 2015 by Zorro2212 (CC BY-SA 4.0)

Slide 8

Slide 8 text

ORGANIZATIONAL SCALING Nah. It’s all about

Slide 9

Slide 9 text

Let me explain • A successful organization grows – More products – More teams – More visibility – More liability – More responsibility! Image: Evolution Logo Wikimedia by Johanna Pung (CC BY-SA 3.0)

Slide 10

Slide 10 text

Let me explain • But as you grow… • Products become interdependent – And so do teams – Incurring a synchronization cost • “… so what”, you say? Image: SVG Graph illustrating Amdahl's law by Daniels220 (CC BY-SA 3.0)

Slide 11

Slide 11 text

Let me explain • Four metrics of high- performing† organizations: – Lead Time – Deployment Frequency – MTTR – Change Fail Percentage • All negatively affected by synchronization! † Per “Accelerate” by Forsgren, Humble and Kim (IT Revolution Press, 2018)

Slide 12

Slide 12 text

Let me explain • So we’re shooting for: – Minimizing synchronization – Maximizing independence • Microservices are a great fit! Image: Aerial view of Watsonville, California, USA by Robert Campbell (CC BY-SA 3.0)

Slide 13

Slide 13 text

2. LESSONS LEARNED

Slide 14

Slide 14 text

Small is Good • Less code = less bugs • Smaller interfaces – Easier to reason about – Easier to evolve – (hard to keep small) • Results in lower coupling

Slide 15

Slide 15 text

Polyglot Ahoy Company # Languages Google 6 Facebook 9 Twitter 4 Amazon 3 Netflix ~3 Spotify 4 • The great promise of microservices • Multiple stacks! • You ain’t gonna need it • You ain’t gonna want it • But it sure feels nice

Slide 16

Slide 16 text

Conway Knows “Organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations.” -- Melvin E. Conway

Slide 17

Slide 17 text

Conway Knows • Common danger signs: – One data store owned by multiple services – Single system owned by multiple teams • If you’re violating SRP… – Reorganize your services – … or your teams! Image: 03053904 by Jerry Norbury via Flickr (CC BY-ND 2.0)

Slide 18

Slide 18 text

Operations Matter • Developer velocity = ship fast and strong • No bottlenecks allowed! – Global release – Centralized ops – Manual deployment – Static topology

Slide 19

Slide 19 text

Operations Matter • Developer velocity = ship fast and strong • No bottlenecks allowed! – Global release ⇨ Many small, rapid iterations – Centralized ops – Manual deployment – Static topology

Slide 20

Slide 20 text

Operations Matter • Developer velocity = ship fast and strong • No bottlenecks allowed! – Global release ⇨ Many small, rapid iterations – Centralized ops ⇨ Distributed ownership – Manual deployment – Static topology

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Operations Matter • Automation is key – Infrastructure – Deployment – Monitoring – Remediation – Provisioning • Automation empowers your teams!

Slide 24

Slide 24 text

3. LESSONS WE HAVEN’T LEARNED Image: “If at first you don't succeed...” by Adam Fagen via Flickr (CC NC-SA 2.0)

Slide 25

Slide 25 text

The Laws of Physics We wouldn’t design an airplane … while ignoring this guy Images: Landing at Madrid-Barajas airport by José A. Montes (CC BY 2.0) and Portrait of Sir Isaac Newton, oil on canvas (public domain)

Slide 26

Slide 26 text

The Laws of Physics Why, then, do we ignore them … when designing these? Images: Leslie Lamport (from personal site), Eric Brewer at TNW Conference (CC BY-SA 4.0), and A diagram of the proposed system architecture by EpochFail (CC BY-SA 3.0)

Slide 27

Slide 27 text

The Laws of Physics • We are all building distributed systems • Concurrency is key • Disregarding CAP means… – You will end up with inconsistent data – You will not scale – You will lose data Image: The Scream by Edvard Munch (public domain)

Slide 28

Slide 28 text

Observability • Distributed systems are, by nature… – Disaggregate – Hard to reason about • We are still deficient – In tooling – In methodology Image via PXHere (CC0 public domain)

Slide 29

Slide 29 text

Observability • Tooling is getting better! – Tracing (Jaeger, Zipkin) – Metrics (Grafana, Prometheus) – Log aggregation (ELK et al) • … but that’s not enough

Slide 30

Slide 30 text

Observability • When you can’t debug in isolation… • You have to know: – What to log – What to count – What to monitor – How to make sense of it all!

Slide 31

Slide 31 text

4. THE BIG REVEAL Image: The Unveiling by nate.stevens via Flickr (CC BY-NC-ND 2.0)

Slide 32

Slide 32 text

Quick Recap • We aim to: – Minimize synchronization – Maximize independence • We’re struggling with: – Safety – Scalability – Observability Image: Retrospective - Good by Denis De Mesmaeker via Flickr (CC BY-NC-ND 2.0)

Slide 33

Slide 33 text

Events • They are your friends • Events make everything simpler • No, really. Much simpler • Let’s explore how Image: Ledger by Shea Smith via Flickr (CC BY 2.0)

Slide 34

Slide 34 text

Events • Modeling interactions with events: – Enforces strong context boundaries – Lets you scale services independently – Lets you observe the system in motion – Increases system reliability Client User Service Onboarding Service Search Service Analytics Event Bus RPC

Slide 35

Slide 35 text

Events • Persisting event streams (event sourcing): – Observability is built in! – (as is auditing) – Lets you scale use cases independently (CQRS) • Precludes full consistency – This is a good thingTM Opened Account Deposited $100 Withdrawn $25 Deposited $12 Balance: $87

Slide 36

Slide 36 text

Events • Modeling workflows in terms of events… – Enables sagas – A pattern for cross- domain consistency – A viable alternative to transactions! – (in most cases) Sagas, Garcia-Molina and Salem, SIGMOD 1987

Slide 37

Slide 37 text

SWEAT THE PRINCIPLES Not the implementation details.

Slide 38

Slide 38 text

Commoditization • A lot has changed • We have tools now! – gRPC, Thrift, Avro – Kafka – Docker, Kubernetes – Spinnaker • No need to roll your own (less so, anyway)! Image via opensource.com (CC BY-SA)

Slide 39

Slide 39 text

Expertise • Invest in studying: – CAP tradeoffs – Domain modelling – Event storming – Event sourcing/CQRS – Sagas • You’ll be better off! Image: Back to School by Phil Roeder via Flickr (CC BY 2.0)

Slide 40

Slide 40 text

Further Reading Design Microservice Architectures the Right Way Michael Bryzek An Abriged Guide to Event Sourcing Tomer Gabel

Slide 41

Slide 41 text

QUESTIONS? Thank you for listening [email protected] @tomerg On GitHub: https://github.com/holograph This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.