Distributed Systems - Like It Or Not
Download as PPTX, PDF3 likes921 views
The document discusses the evolution and complexities of distributed systems, highlighting key historical milestones from single-user systems to predominantly distributed architectures. It emphasizes the challenges faced in understanding time, causality, and failures within distributed environments, such as pathological timing failures and the need for consensus mechanisms. Ultimately, it underscores that modern software development requires every developer to grasp distributed principles due to the pervasive nature of such systems.
Distributed Systems - Like It Or Not
- 1. Distributed Systems LIKE IT OR NOT http://l42.org/JAE
- 2. Theo Schlossnagle CEO @Circonus Twitter: @postwait
- 3. Beginning of Software Mass Production. Ship Install Run Disconnected.
- 4. Things got connected. We built connected software like disconnected software. Either thick with updates (new versions) available online. Or it was thin with all logic on the server side. The Cable Guy © unknown
- 5. Distributed Applications (examples) The Web MVC MC on the server V In the browser PoS Applications Inventory on main server Inventory, sales on client HPC Coordinated progress: Central jobs, disitributed work.
- 6. Distributed Backends Changed Everything Ratio of Affected users to Node failures
- 7. The Mysteries of Distributed Failure Some things are best described through poetry It's not DNS There's no way it's DNS It was DNS - SSBroski
- 8. Progression of Understanding 1990 • Single user • Single system 1995 • Distributed users • Single system 2000 • Single user* • Distributed systems 2005 • Distributed users • Distributed systems * Lack of tech and understanding to understand both distributed users and systems.
- 9. Distributed Systems Are Unavoidable Almost every system you build today will be distributed. Most single systems have multiple processors of different architectures with different clock speeds (think GPU); the distributed nature is mostly hidden.
- 10. #1 Clocks & Time With 1 clock, you know the time. With 2+ clocks, you never know the time. You must think distributed. Leslie Lamport, Turing Award Winner: http://l42.org/HgE Colin Fidge: http://l42.org/IgE
- 12. #2 Causal thinking, but with all possible initial states. That debugging step of understanding prior state still exists: more possible states, harder to constrain, and no clocks (#1) http://l42.org/HAE
- 13. #3 One person’s failure, is another’s Byzantine tragedy. Arguably reasonable isolated behavior can have pathologically bad system behavior. http://l42.org/HQE
- 14. Pathological Timing Failures The most common failure conditions are timeout related (in my experience) Mismanaged and awkwardly aligned timeouts can cause pathological and unstable situations.
- 15. #4 Understand Consensus Paxos – Lamport http://l42.org/IQE Raft – Ongaro & Ousterhout http://l42.org/IAE VS – Birman http://l42.org/HwE
- 16. Microservices SOA Cloud The democratization of useful services has shifted the burden of understanding distributed systems from “distributed systems engineers” to every developer everywhere.
- 17. Is it all worth it? Modular development Language domains Security domains Availability domains Resiliency domains
- 18. Many Distributed Situations Make Little Initial Sense
- 19. Pathology Pathology: concerned with diagnosis of issues via post-event analysis (coopted from medicine) Pathological: involving, caused by, or the nature of a physical or mental disease or obsessive or compulsive