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

Reactive Principles

D37e5ab989819a805126efe1535d08da?s=47 Kod.io
October 26, 2013

Reactive Principles

By Barış Daylık
http://kod.io

D37e5ab989819a805126efe1535d08da?s=128

Kod.io

October 26, 2013
Tweet

More Decks by Kod.io

Other Decks in Programming

Transcript

  1. Reactive Principles Barış Can Daylık baris@vngrs.com

  2. Agenda • Current application requirements • Traditional Solutions • New

    Architecture (Reactive) – Event-Driven – Scalable – Resilient – Responsive • Final Words
  3. Current application requirements • Before – Tens of servers –

    Seconds of response time – Hours of offline maintenance – Gigabytes of data • Now – Diverse platforms (i.e. from mobile devices to cloud-based clusters on thousands of multicore processors) – Millisecond to microsecond response times – 100% uptime – Petabytes of data
  4. Traditional Solutions • Dedicated Bare-Metal Servers • Vertical Scaling (buying

    larger servers) • Multi-threading for concurrency • Adding servers are complex and expensive • Not easy to manage
  5. Traditional Solutions • Traditional Server Architecture – Multi Threading –

    Shared Mutable State • Synchronization/Locks • Non-Deterministic/Race Conditions • Code is hard to understand and maintain – Blocking a single thread • Resource consuming • High wake-up cost
  6. New Architecture • Satisfies todays demands • Reactive Applications –

    Event-driven – Scalable – Resilient (Fault-Tolerant) – Responsive
  7. New Architecture • Satisfies todays demands • Reactive Applications –

    Event-driven – Scalable – Resilient (Fault-Tolerant) – Responsive
  8. New Architecture • Reactive applications – react to events (Event-Driven)

    – react to load (Scalable) – react to failure (Resilient) – react to users (Responsive)
  9. Event-Driven • Interacts through producing and consuming events • Asynchronous

    message passing – Easy parallelization • Loose Coupling – Separated Producer and Consumer – Hiding the details of event propagation and communication – Location Independence – Easy to extend – Easy to maintain – Providing flexibility while programming
  10. Event-Driven • Non-Blocking – Sharing the same thread among multiple

    consumers – Higher throughput – Lower latency – Effective hardware utilization and lower costs • Push based – Resources not wasted by polling or waiting on data
  11. Event-Driven • Application must be event- driven from UI down

    to the Database.
  12. Event-Driven • Even if %5 of the whole application is

    sequential, total speedup will be limited to 20x, according to Amdahl's law. Amdahl's Law
  13. Scalable • Scalable application – Capable of being easily expanded

    or upgraded on demand based on its usage – Scale up or down without redesign/rewrite – Cost effective on cloud deployments as it can grow or shrink elastically based on usage
  14. Scalable • Loose coupling and location independence of event- driven

    system makes it easy to scale • Easy to add more event consumers • No difference between vertical/horizontal scaling
  15. Resilient • Recover quickly from failures • Application downtime –

    Nightmare of a business – Halts revenue stream – Causes unhappy customers and poor reputation
  16. Resilient • Traditional Applications – Ignored fail scenarios – Exception

    handling • Not all problems can be dealt with where they occur – Clustered servers • Failover for whole application • Recovery is time consuming thus costly • Potential risk of cascading failures
  17. Resilient • Reactive Applications – Resilience is part of the

    design – Failure is a first class construct • Easier to react and manage • Auto healing of component instead of application failover
  18. Resilient • To manage failure – Isolate to prevent cascading

    failures – Observe to detect it whenever it happens, not when its too late • Event-driven model to the rescue – Full isolation as a result of loose coupling – Failures can be packaged and sent as events where other components decides how to deal with it – Helps keeping business flow clear and lets you deal with failure in a more rigid and planned way – Location transparent
  19. Responsive • Its not HTML5 responsive design :) • Responsive

    Applications are – Quick to respond and react – Responds fast even in case of failure • Not responding in a timely manner – Might cause total failure (Medical Systems) – Decreased utility (Finance, Telco, Internet)
  20. Responsive • Observable Models – Triggers events on state changes

    – Makes it possible to synchronize between remote clients • Event Streams – Asynchronous and non-blocking communications
  21. Final Words • Reactive applications has four traits – Event-Driven

    – Scalable – Resilient – Responsive • Complements each other forming a whole • Addresses common problems with current challenges in application design
  22. Don't forget to check these out • Reactive Manifesto :

    http://www.reactivemanifesto.org/ • ReactiveMongo : http://reactivemongo.org/ • Akka : http://akka.io/ • Play : http://www.playframework.com/ • Reactive Activator Template http://typesafe.com/activator/template/tcp-async
  23. We Are Hiring! info@vngrs.com