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

Software Architecture for Distributed Systems

Felix Raab
January 09, 2019
230

Software Architecture for Distributed Systems

Topics covered are software architecture basics, distribution, and architecture for distributed systems.

Felix Raab

January 09, 2019
Tweet

Transcript

  1. KI UNIVERSITY DISTRIBUTED SYSTEMS “A distributed system is one in

    which the failure of a computer you didn’t even know existed can render your own computer unusable.” Leslie Lamport, 1987
  2. KI UNIVERSITY DON’T DISTRIBUTE “My First Law of Distributed Object

    Design: Don't distribute your objects” Martin Fowler, 2002
  3. KI UNIVERSITY TERRIBLE DISTRIBUTED SYSTEMS “Everything about distributed systems is

    terrible.” Hillel Wayne, 2018 We’ll come back to that at the end of the talk…
  4. ▸ The classic way (a good foundation for a monolithic

    app): 3-tier, n-tier, … KI UNIVERSITY LAYERED ARCHITECTURE PRESENTATION BUSINESS LOGIC PERSISTENCE Separation of Concerns? Kind of…(technical separation) – but how do you slice it for business-related functionality?
  5. KI UNIVERSITY DOMAINS… ▸ Structure functionality around business domains ▸

    Towards “vertical slices” ▸ Tactical Patterns
  6. KI UNIVERSITY “ONION” MICROSERVICE ▸ Simple rule: Outside depends on

    inside (but not the other way round) ▸ Outside: HTTP, Database (the inputs and outputs of the system). Inside: Domain Concepts (the “business rules”)
  7. KI UNIVERSITY DISTRIBUTION ▸ Multiple services – sync. point-to-point communication

    – what can possibly go wrong? SERVICE A SERVICE B ▸ A lot: Failure, Maintenance, Overloaded, etc.
  8. KI UNIVERSITY THE FALLACIES OF DISTRIBUTED SYSTEMS ▸ The network

    is reliable. ▸ Latency is zero. ▸ Bandwidth is infinite. ▸ The network is secure. ▸ Topology doesn't change. ▸ There is one administrator. ▸ Transport cost is zero. ▸ The network is homogeneous. Source: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
  9. KI UNIVERSITY ROBUSTNESS ▸ Retries (ideally with exponential back-off) ▸

    Circuit Breakers (Pattern for broken services not being called again until they recover)
  10. KI UNIVERSITY TAIL LATENCY AMPLIFICATION SERVICE BACKEND A BACKEND B

    BACKEND C ▸ Parallel fan out: A single slow backend can slow everything down. The more backends are involved, the higher the proportion of upstream service requests that will be slow. ▸ Possible solutions: Caching, sending more requests and using the fastest, timeouts, etc. “The Tail at Scale”: https://dl.acm.org/citation.cfm?doid=2408776.2408794
  11. KI UNIVERSITY ▸ Service Meshes and Side Car Proxies MANY

    SERVICES… Source: https://www.infoq.com/articles/microservices-post-kubernetes
  12. KI UNIVERSITY TIME TO THINK… ▸ Suppose you built a

    monolithic web application where users can publish blog posts. The posts are stored in a database (table). Now you want to add a new feature that recommends blog posts to users. ▸ From an architectural perspective, you want to handle the recommendation feature through a new service. How would you design the service and add it to the existing architecture? (Backend Engineering Interview Question – inspired by Medium Engineering)
  13. KI UNIVERSITY WHAT ABOUT THIS DESIGN? (1) WEB APP POSTS

    TABLE RECO SERVICE CACHE ▸ If web app changes storage of posts, reco service needs to adapt. ▸ Logic based on posts data would need to be re-implemented in reco service.
  14. KI UNIVERSITY WHAT ABOUT THIS DESIGN? (2) WEB APP POSTS

    TABLE RECO SERVICE POSTS SERVICE CACHE ▸ Access posts data through new posts service API, which fully owns all posts data.
  15. KI UNIVERSITY WHAT ABOUT THIS DESIGN? (3) ▸ Push post

    changes to queue, reco service maintains its own data for relevant posts. WEB APP POSTS TABLE QUEUE CACHE RECO SERVICE RECO DATA CACHE
  16. KI UNIVERSITY OPTION 4 “The hardest part of microservices is

    your data”: https://www.youtube.com/watch?v=MrV0DqTqpFU
  17. KI UNIVERSITY DB SHARING ▸ Sharing a database between (micro)services

    can be ok! (while sharing data / tables is often not ok). ▸ Also think about deployment complexity, cloud costs…
  18. KI UNIVERSITY DESIRABLE GOAL: SERVICE ISOLATION ▸ Isolation of Time

    (Async. communication, events) ▸ Isolation of State (Data Ownership, no table sharing, communicate through APIs) ▸ Isolation of Space (Don’t depend on location of other service, support deployment across many machines) ▸ Isolation of Failures (Failure in a service does not bring down whole system) Source: https://corecursive.com/22-big-ball-of-mud-architecture-and-services-with-wade-waldron/
  19. KI UNIVERSITY BREAKING UP MONOLITHS ▸ Refactoring, service extraction principles

    “How to extract a data-rich service from a monolith”: https://martinfowler.com/articles/extract-data-rich-service.html
  20. KI UNIVERSITY NOT DISCUSSED ▸ Communication Protocols (JSON, gRPC, …)

    ▸ Observability (Monitoring, Tracing, …) ▸ Deployment: Containers, Serverless, Lightweight VMs, … ▸ …
  21. KI UNIVERSITY TLA+ ▸ Specification language for concurrent systems, invented

    by Leslie Lamport ▸ Increasingly used in industry to design for reliability and correctness (e.g. by AWS, used for the replication protocol of Azure’s Cosmos DB) https://www.youtube.com/watch?v=tfnldxWlOhM