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.
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.
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
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
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
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
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.
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
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.
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
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
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
peschlowp
nikkei_engineer_recruiting
sinsoku
hanaseleb
mosa_siru
replu
tomoaki25
yoshiitaka
you
takesection
sekido
hhiroshell
ysasago
rmw
62gerente
bkeepers
dougneiner
jennybc
chriscoyier
holman
speakerdeck
andyhume