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

Reactive Programming

Reactive Programming

Presentation held at the Parallel Conference in Karlsruhe, Germany, on May 6, 2014. Apart from the slides, the presentation featured a demo of RxJava, highlighting its strengths and some of its current limitations.

00655e17a4f690cb462153f921f8eb77?s=128

Patrick Peschlow

May 06, 2014
Tweet

Transcript

  1. codecentric AG Patrick Peschlow Reactive Programming

  2. codecentric AG The Challenge Users

  3. codecentric AG The Challenge Users don’t like to wait

  4. codecentric AG The Challenge Users don’t wait

  5. codecentric AG The Challenge Many users don’t wait

  6. codecentric AG The Challenge Many many users don’t wait

  7. codecentric AG The Challenge Today’s applications don’t cope

  8. codecentric AG So we need a Manifesto

  9. codecentric AG Reactive Traits From: http://www.reactivemanifesto.org

  10. codecentric AG Event-driven Trait − Asynchronous − Synchronous APIs tightly

    couple client and service (often block) − Asynchronous means the client can decide if and where to block ! − Non-blocking − Blocking APIs may require large numbers of threads (often coupled to users) − Wastes CPU resources (context switches, scheduling) − Non-blocking frees threads to do new work − Define worker thread pools based on resources ! − Share nothing ! − Loose coupling Based on: Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Chapter 1 preview.
  11. codecentric AG Example Time Scale of System Latencies From: Brendan

    Gregg. „Systems Performance: Enterprise and the Cloud“. Prentice Hall, 2013
  12. codecentric AG Futures and Promises − Future: A reference to

    an asynchronously computed value ! − Promise: A future with additional features − May be completed in various ways (e.g., by a setter) − Enables composition (one promise completes another) ! − (Functional) Reactive Programming − Futures and promises taking to the extreme
  13. codecentric AG Futures and Promises Demo

  14. codecentric AG RxJava Reactive Extensions for the JVM — A

    library for composing
 asynchronous and event-based programs using observable sequences for the Java VM From: http://github.com/Netflix/RxJava
  15. codecentric AG Observable single items multiple items synchronous T  getData()

    Iterable<T>  getData() asynchronous Future<T>  getData() Observable<T>  getData() From: http://github.com/Netflix/RxJava/wiki
  16. codecentric AG Observable From: http://github.com/Netflix/RxJava/wiki Iterable (pull) Observable (push) T

     next() onNext(T) throws Exception onError(Exception) returns onCompleted()
  17. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html

  18. codecentric AG RxJava Demo

  19. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html

  20. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html

  21. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html

  22. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html

  23. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html

  24. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html

  25. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html

  26. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html

  27. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html

  28. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html

  29. codecentric AG Benefits of Observables − Life cycle of client

    and service are decoupled ! − Service API keeps control over its implementation ! − Client decides how its subscription should behave (e.g., timeouts) ! − Note: The „client“ may be another service having its own clients − Not necessarily a human or a browser
  30. codecentric AG Back Pressure − An eager producer can overflow

    its consumer(s) − Due to inversion of control when going from sync to async ! − Consumers need a mechanism for „back pressure“ − Tell the producer how much data you can handle − Similar to, e.g., receiver window in TCP From: http://www.reactive-streams.org
  31. codecentric AG So are we Reactive yet? From: http://www.reactivemanifesto.org

  32. codecentric AG Responsive Trait − Goal: Achieve bounded latency !

    − Parallelize tasks within services ! − Choose algorithms with small variance in execution time − Predictable execution time for some target percentile ! − Use explicit and bounded queues ! − Use circuit breakers that monitor target metrics and react on violation − fail-fast and reject, return partial results, or delegate to another service − e.g., for input queues, reject requests when the queue is full Based on: Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Chapter 1 preview.
  33. codecentric AG Resilient Trait − Goal: Service stays available even

    in the presence of unexpected failures − software, hardware, human ! − Distribute the system ! − Use bulkheading ! ! ! ! − Let supervisors handle failure − separate failure handling from the actual business logic of the service Based on: Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Chapter 1 preview. From: http://www.reactivemanifesto.org
  34. codecentric AG Scalable Trait − Goal: Scale up (and down)

    based on load ! − Distribute requests to various instances of the services ! − The more stateless services, the better ! − Measure load at run time and react accordingly − But: No reason to forego capacity planning Based on: Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Chapter 1 preview.
  35. codecentric AG What about Actors? − Seem to fulfill the

    reactive traits much better than reactive programming does − Asynchronous, non-blocking, and event-driven by definition − Supervisors and „let it crash“ − Distributed − Easily scalable ! − But maybe too „heavyweight“ for some problems within services − Often, stateless actors don’t suffice or get highly complex ! − Promising approach: Combine actors and reactive programming − Actors for the backbone and cluster „infrastructure“ − Reactive Programming inside the nodes
  36. codecentric AG Conclusion − Clear need for reactive applications !

    − Well addressed by the actor model and reactive programming approaches ! − Building reactive applications requires different thinking ! − Helped by various reactive frameworks, in particular on the JVM ! − Brings up the topic of essential complexity vs. incidental complexity
  37. codecentric AG Frameworks − Reactive Extensions (Rx)
 http://rx.codeplex.com ! −

    RxJava
 http://github.com/Netflix/RxJava ! − Akka
 http://akka.io ! − Vert.x
 http://vertx.io ! − Reactor
 https://github.com/reactor/reactor
  38. codecentric AG Resources − Reactive Manifesto
 http://www.reactivemanifesto.org ! − Reactive

    Streams
 http://www.reactive-streams.org ! − Conference „React 2014“
 http://reactconf.com
 http://www.youtube.com/user/reactconf ! − Online course on Reactive Programming
 http://www.coursera.org/course/reactive ! − Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Currently in writing. ! − Michael Nygard. „Release It!“. Pragmatic Bookshelf. 2007.
  39. codecentric AG Questions? Dr. rer. nat. Patrick Peschlow
 codecentric AG


    Merscheider Straße 1
 42699 Solingen
 
 tel +49 (0) 212.23 36 28 54
 fax +49 (0) 212.23 36 28 79
 patrick.peschlow@codecentric.de
 
 www.codecentric.de
  40. codecentric AG Bonus: What does this mean for my (Big)

    Data? − If reactive applications focus so much on availability, what about consistency − CAP suggests you need to choose between C and A ! − But: Even with CAP you can have C and A most of the time − You just need to have a reliable strategy for detecting and handling partitions − http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed ! − Note: There is also a „Reactive Programming“ in the context of databases − http://www.espressologic.com/reactive-programming-database-logic/ − Don’t confuse it with the „Functional Reactive Programming“ we have seen