SOFTWARE ARCHITECTURE FOR DISTRIBUTED SYSTEMS KI UNIVERSITY, 9.1.2019

KI UNIVERSITY OUTLINE ARCHITECTURE DISTRIBUTION DISTRIBUTED ARCHITECTURE FOR THE HARD-BOILED…

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

KI UNIVERSITY DON’T DISTRIBUTE “My First Law of Distributed Object Design: Don't distribute your objects” Martin Fowler, 2002

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…

KI UNIVERSITY BUT WE DON’T LISTEN… Distribute things like never before!!! https://xkcd.com/1546/

KI UNIVERSITY ARCHITECTURE

▸ 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?

KI UNIVERSITY DOMAINS… ▸ Structure functionality around business domains ▸ Towards “vertical slices” ▸ Tactical Patterns

KI UNIVERSITY LAYERS, HEXAGONS, FEATURES, COMPONENTS Source: http://www.codingthearchitecture.com/2016/04/25/layers_hexagons_features_and_components.html

KI UNIVERSITY HEXAGONAL ARCHITECTURE (WHY HEXAGON?…) https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/

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

KI UNIVERSITY DISTRIBUTION

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.

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

KI UNIVERSITY ROBUSTNESS ▸ Retries (ideally with exponential back-off) ▸ Circuit Breakers (Pattern for broken services not being called again until they recover)

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

KI UNIVERSITY ▸ Service Meshes and Side Car Proxies MANY SERVICES… Source: https://www.infoq.com/articles/microservices-post-kubernetes

KI UNIVERSITY DISTRIBUTED ARCHITECTURE

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)

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.

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.

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

KI UNIVERSITY OPTION 4 “The hardest part of microservices is your data”: https://www.youtube.com/watch?v=MrV0DqTqpFU

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…

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/

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

KI UNIVERSITY NOT DISCUSSED ▸ Communication Protocols (JSON, gRPC, …) ▸ Observability (Monitoring, Tracing, …) ▸ Deployment: Containers, Serverless, Lightweight VMs, … ▸ …

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

KI UNIVERSITY THE END