Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Designing Distributed
Systems
Malisa Ncube
inbox@malisancube.com
malisancube.com
What this talk is about
 The distributed Paradigm
 Reactive Manifesto
 Cloud computing considerations
 Akka
What is a distributed computing
“Distributed computing is a field of computer science that studies distributed
systems. A ...
What is cloud computing?
 Lets the platform do the hard stuff by leveraging the application services.
 Uses non-blocking...
What are microservices?
 In computing, microservices is a software architecture style in which
complex applications are c...
Moore's law
Brewers CAP thorem
 Eric Brewer introduced the idea that there is a fundamental trade-off between
consistency, availabili...
Amdahl’s Law
Gives the theoretical speedup in latency of the execution of a task at
fixed workload that can be expected of...
Concerns
Horizontal scaling compute Pattern
 Horizontal scaling is reversible.
 Supports scaling out and scaling in
 Stateful no...
Queue-Centric Workflow Pattern
 Used in web applications to decouple communication between web-tier and service
tier by f...
Eventual Consistency
 Simultaneous requests for the same data may result in different values.
 Leads to better performan...
Busy Signal Pattern
 Applies to services or resources accessed over a network where a signal response
is busy.
 These ma...
Some Concerns
 Node Failure Pattern
 Concerns availability and graceful handling of unexpected application/hardware fail...
Traditional systems
Traits of a reactive system
 scalable (react to load, minimize contention) scale up/out
 responsive
 resilient (has to ...
The reactive manifesto
Responsive
Message
Driven
ResilientElastic
http://www.reactivemanifesto.org/
Actors
The Actor Model
 The actor model in computer science is a mathematical model of concurrent
computation that treats "actor...
In different scenarios, an Actor may be an
alternative to:
 a thread
 an object instance or component
 a callback or li...
The structure of Akka
Actors
 - Simple add high level abstractions for concurrency and parallelism
 - Asynchronous, non-blocking and highly ev...
Multi threads vs Multi Actors
 1 MB per thread (4MB in 64 bit) vs 2.7 million actors per gigabyte
More on Actors
 Let it crash philosophy
 The failure strategies
 One for one supervision
 All for one. One node crashe...
Some Code
References
Akka - http://akka.io
Reactive Extensions - http://reactivex.io/
Halo - https://www.halowaypoint.com/en-us/game...
That’s all friends
 Malisa Ncube
 @malisancube
 http://malisancube.com
Designing distributed systems
Upcoming SlideShare
Loading in …5
×

Designing distributed systems

772 views

Published on

Designing Distributed Systems for Geeknight Kampala 26th April 2016. Cloud patterns

Published in: Software
  • Be the first to comment

Designing distributed systems

  1. 1. Designing Distributed Systems Malisa Ncube inbox@malisancube.com malisancube.com
  2. 2. What this talk is about  The distributed Paradigm  Reactive Manifesto  Cloud computing considerations  Akka
  3. 3. What is a distributed computing “Distributed computing is a field of computer science that studies distributed systems. A distributed system is a software system in which components located on networked computers communicate and coordinate their actions by passing messages.” https://en.wikipedia.org/wiki/Distributed_computing
  4. 4. What is cloud computing?  Lets the platform do the hard stuff by leveraging the application services.  Uses non-blocking asynchronous communication in a loosely coupled architecture.  Scales horizontally in an elastic mechanism.  Does not waste resources  Handles scaling events, node failures, transient failures without downtime or performance degradation.  Uses geographic distribution to minimize network latency.  Upgrades without downtime.  Scales automatically using proactive and reactive actions.  Monitors and manages application logs as nodes come and go.
  5. 5. What are microservices?  In computing, microservices is a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language- agnostic APIs.[1] These services are small building blocks, highlydecoupled and focussed on doing a small task, facilitating a modular approach to system- building.[5]
  6. 6. Moore's law
  7. 7. Brewers CAP thorem  Eric Brewer introduced the idea that there is a fundamental trade-off between consistency, availability, and partition tolerance.  In a network subject to communication failures, it is impossible for any web service to implement an atomic read/write shared memory that guarantees a response to every request.
  8. 8. Amdahl’s Law Gives the theoretical speedup in latency of the execution of a task at fixed workload that can be expected of a system whose resources are improved.
  9. 9. Concerns
  10. 10. Horizontal scaling compute Pattern  Horizontal scaling is reversible.  Supports scaling out and scaling in  Stateful nodes  They keep user session information  They have single point of failure  Stateless nodes  Store session information externally from the nodes.
  11. 11. Queue-Centric Workflow Pattern  Used in web applications to decouple communication between web-tier and service tier by focusing on the flow of commands.  A service tier that is unreliable or slow can affect the web tier negatively.  All communication is asynchronous as message over a queue  The sender and receiver are loosely coupled. Neither one knows about the implementation of the other.  There is some edge cases where the risk of invisibility windows occurs when processing takes longer than allowed.  Idempotency concerns. Database transactions, compensating transaction.  Poison messages placed in dead letter queue.  QCW is not full CQRS as it does not articulate the read model.
  12. 12. Eventual Consistency  Simultaneous requests for the same data may result in different values.  Leads to better performance and lower cost.  Uses Brewer’s CAP theorem (Consistency Availability and Partition tolerance). 3 Guarantees and application an pick only 2.  Consistency. Everyone get the same answer.  Availability. Clients have ongoing access (even if there is a partial system failure)  Partition tolerance. Means correct operation even if some nodes are cut of from the network.  DNS updates and NoSQL are examples of eventually consistent services.
  13. 13. Busy Signal Pattern  Applies to services or resources accessed over a network where a signal response is busy.  These may include management, data services and more, and periodic transient failure should be expected. E.g. Busy signal on telephones.  A good application should be able to handle retries and properly handle failures.  On HTTP. Response 503 Service Unavailable.  Clearly identify Busy Signal and Errors and retry on Busy state after an interval. Log them for further analysis of patterns.
  14. 14. Some Concerns  Node Failure Pattern  Concerns availability and graceful handling of unexpected application/hardware failures, reboots or node shutdown.  Application state should be in reliable storage, not on local disk or individual node  Network latency problem  Move application data closer to users  Ensure nodes within your application are closer together (Colocation)  WA uses Affinity Groups  Consider Data Compression, Background processing, Predictive Fetching, CDN
  15. 15. Traditional systems
  16. 16. Traits of a reactive system  scalable (react to load, minimize contention) scale up/out  responsive  resilient (has to be bolted by design, things will fail, isolation of components and preventing cascading failures)  event driven (asynchronous)
  17. 17. The reactive manifesto Responsive Message Driven ResilientElastic http://www.reactivemanifesto.org/
  18. 18. Actors
  19. 19. The Actor Model  The actor model in computer science is a mathematical model of concurrent computation that treats "actors" as the universal primitives of concurrent computation.  In response to a message that it receives, an actor can: make local decisions, create more actors, send more messages, and determine how to respond to the next message received. Actors may modify private state, but can only affect each other through messages (avoiding the need for any locks)
  20. 20. In different scenarios, an Actor may be an alternative to:  a thread  an object instance or component  a callback or listener  a singleton or service  a router; load-balancer or pool  a Java EE Session Bean or Message-Driven Bean  an out-of-process service  a Finite State Machine (FSM)
  21. 21. The structure of Akka
  22. 22. Actors  - Simple add high level abstractions for concurrency and parallelism  - Asynchronous, non-blocking and highly event driven programming model  Fault tolerance  Supervisor hierarchies with let-it-crash semantics  Supervisor hierarchies can san multiple VMs  Excellent for writing highly fault tolerant systems that self heal and never stop  Location Transparency  Everything akk is designed to work in distributed environment: All interactions of actors use pure message passing and everything is asynchronous  akka.tcp://MySystem@localhost:9001/user/actorName1
  23. 23. Multi threads vs Multi Actors  1 MB per thread (4MB in 64 bit) vs 2.7 million actors per gigabyte
  24. 24. More on Actors  Let it crash philosophy  The failure strategies  One for one supervision  All for one. One node crashes the siblings will be restarted
  25. 25. Some Code
  26. 26. References Akka - http://akka.io Reactive Extensions - http://reactivex.io/ Halo - https://www.halowaypoint.com/en-us/games Carl Hewitt - http://en.wikipedia.org/wiki/Carl_Hewitt Orbit Framework - https://github.com/electronicarts/orbit,http://orbit.bioware.com/ Project Orleans - https://github.com/dotnet/orleans
  27. 27. That’s all friends  Malisa Ncube  @malisancube  http://malisancube.com

×