Intro to distributed systems
14 likes1,252 views
Distributed systems address challenges like capacity constraints, availability issues, and performance limitations by utilizing a network of diverse computing resources. Key concerns include heterogeneity, transparency, concurrency, coordination, scalability, resilience, and security, requiring thoughtful design and trade-offs in system architecture. As these systems evolve, they offer greater complexity and sophistication, impacting both development practices and business outcomes.
Intro to distributed systems
- 1. Distributed Systems and why you should care! Ahmed Soliman â«Ű§ÙâŹâ«Ù âŹâ«ÙâŹâ«ŰłÙâŹâ«ŰŻâŹâ«ŰÙ âŹâ«ŰŁâŹ
- 4. Wrestling With Capacity Constraints Cannot add more (CPU Cores, RAM, Disk, Network Bandwidth, etc.) to a single box
- 5. Wrestling With Availability Constraints Dealing with failures of (Network, Power, Hard-drives, Faulty Ram, etc.)
- 6. Wrestling With Latency/ Performance Constraints Not the entire world is wired with Optical Fibers. Sometimes even the speed of light is not fast enough* it takes 39ms for light to reach from Cairo to Dallas.
- 7. Welcome to Distributed Systems The world is a mesh of very large and very small computers with a utterly sophisticated networking medium in between
- 8. itâs everywhere! The web is currently the worldâs largest distributed system, mobile is getting even larger, wearables will make the web-scale look like ant to an elephant!
- 9. Computing was never that sophisticated and itâs getting even more sophisticated every single day.
- 10. Some Challenges âą Heterogeneity and Abstractions âą Transparency and Abstractions âą Concurrency and Coordination âą Scalability âą Resilience to Failures âą Security
- 12. Heterogeneity âą Different systems will be written in different languages, running on different operating systems, network characteristics, computer architectures, etc. âą Clear boundaries and a set of abstractions must be deïŹned. Think of Micro-service/SOA architecture, RESTful APIs, Thrift/Protobuf/Avro/msgpack/etc. for efïŹcient binary message serialization across systems
- 13. Heterogeneity and Abstractions âą Abstractions through interfaces exposed through the network (think of sockets as low-level abstraction) âą Higher-level abstractions of data formats (json/thrift/protobuf/ avro/etc.), protocols like HTTP, XMLRPC, Thrift-RPC, âą Effective separation offers great ïŹexibility for large-scale development teams and allows the use of the right-tool for the right-job âą Generates a new set of challenges, think of protocols and versioning, cascading failures that are hard to trace, congestion/malfunction traceability is order of magnitude higher
- 14. Transparency âą Systems need to know how to reach other systems âą Central Registry, discovery protocols, gossip protocols âą Components living in the same process vs. inter-process communication (mobility) âą shared-memory or IPC/Unix Sockets/TCP Sockets/etc? âą Higher-level abstraction means that there is no conceptual difference between scaling vertically on multicore or horizontally on the cluster âą Think of failures, restarts, commute of components and their effect on consumers.
- 15. Concurrency âą a multi-user system means that users will be competing against system resources. âą Donât confuse concurrency and parallelism. âą A tricky business, if you think that threading is the best way to handle concurrency you will pay for the cost for thatâŠa lot! âą heisenbugsâą everywhere âą Please welcome, race conditions, dead-locks, locking, barriers, compilers reordering, compiler optimizations, etc.
- 16. Concurrency âą Mutable shared state is the root of most evilâą âą Low-level abstractions (threading) âą Higher-level abstractions in programming languages (co-routines, async in C#, etc.) âą Actor Model (Erlang OTP, Scala/Java Akka, etc.) âą Concurrent but not Parallel using Async IO (NodeJS)
- 17. Coordination âą Low-level coordination primitives from the operating system like mutex, readwrite-locks, reentrant-locks, flock, etc. âą across-systems coordination is sometimes needed âą central registry with atomic semantics âą consensus protocols (paxos, raft, etc.)
- 18. Coordination âą Classical master-writer, slave-reader clustering is an easy ïŹx but proven to scale poorly in write- intensive environments (e.g., social networks) âą Sharding/Partitioning may help in avoiding coordination altogether, still rebalancing, healing is extra work needed. âą CRDT (ConïŹict-free Data Types) maybe one potential solution too.
- 19. Scalability âą Horizontal Scalability vs Vertical Scalability âą Optimization of per-node capacity (req/s) is a third dimension of your scalability design plan âą Single Point of Failures âą Performance Bottlenecks âą Commutative Operations âą Consistency Levels (Strong, Weak, Eventual)
- 20. Resilience âą Ability to sustain high-loads without crashing âą Ability to recover from partial crashes âą Failures should be properly reported to the operation team and gracefully delivered to the client âą Avoidance of cascading failures as possible
- 21. Security âą Authentication and authorization across different systems âą Central authorization vs. state-less authorization âą data conïŹdentiality across different systems âą JWT (Json Web Tokens) as one solution to decentralized authenticity veriïŹcation
- 22. In Short⊠⹠Distributed Systems are much more fun than you think âą Itâs a mixture between science and art âą Itâs about putting the right tradeoffs in place âą It has an immediate business impact, be careful.
- 23. Thank You!