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.
Be Reactive!
What’s happening?
Be Reactive! SUG KL March 2015 Elastic • Ability to scale, but also • be efficient, leverage modern multi- / many-core har...
Be Reactive! SUG KL March 2015 Resilient • Failure is embraced as a regular state in the system • Resilience is a first-cl...
Be Reactive! SUG KL March 2015 Before we get to message-driven • Let’s talk about • Multi-Threading • I/O • Distribution •...
Threads vs. task level concurrency
Be Reactive! SUG KL March 2015 A supposedly great idea • Threads are • lightweight processes • easier programming model, n...
Be Reactive! SUG KL March 2015 Lightweight? 12 Slide stolen from John Rose, Java VM Architect, JFokus, Stockholm, February...
Be Reactive! SUG KL March 2015 The problem with Threads 13 They discard the most essential and appealing properties of seq...
+ Let’s talk about Multi-Threading
Be Reactive! SUG KL March 2015 Threads • not efficient • memory consumption • cost for context switch • shared memory bad ...
Be Reactive! SUG KL March 2015 Tasks Better • task level (sub-thread) concurrency • share nothing approach • # threads ~ #...
Blocking vs. non-blocking I/O
Be Reactive! SUG KL March 2015 High concurrency matters 18 But there’s one thing we can all agree on: At high levels of co...
Be Reactive! SUG KL March 2015 Blocking I/O, Thread-per-request 19 From https://strongloop.com/strongblog/node-js-is-faste...
Be Reactive! SUG KL March 2015 Non-blocking I/O 20 Note: Single Thread is crazy! What about your other cores?
Be Reactive! SUG KL March 2015 Non-blocking 21 For task level (sub-thread level) concurrency • each thread is responsible ...
Distributed Transactions vs. EC
Be Reactive! SUG KL March 2015 Life beyond Distributed Transactions 23 In general, application developers simply do not im...
24 Want Almost-Infinite Scaling
 • More of everything… Year by year, bigger and bigger • If it fits on your machines, mult...
Be Reactive! SUG KL March 2015 Distributed Transactions 25 Distributed Transactions („2PC“) are a source of unnecessary fa...
App Servers vs. Containerless
Be Reactive! SUG KL March 2015 27
Be Reactive! SUG KL March 2015 28
Be Reactive! SUG KL March 2015 Java EE Application Servers 29 Servlet API was developed for thread-per-request, synchronou...
Summary
Be Reactive! SUG KL March 2015 Checklist 31 If • Threads are the smallest unit of concurrency in your code, or • You use b...
Be Reactive! SUG KL March 2015 Want list 32 • Task-level (sub-thread level) concurrency • Non-blocking I/O • Distribution ...
.. gives you all that
Be Reactive! SUG KL March 2015 Message-Driven • Loosely coupled architecture, easier to extend, maintain, evolve • Asynchr...
Go Reactive! Swisscom March 2015 37
Go Reactive! Swisscom March 2015 • We want to be asynchronous and non-blocking • We need to ensure that our data is protec...
Be Reactive! SUG KL March 2015 Where can I find that? 39
Be Reactive! SUG KL March 2015 40 Want to learn more? http://www.typesafe.com http://go.typesafe.com Questions? lutz.huehn...
Be Reactive! at Functional and Reactive Programmers Group, Kaiserslautern March 31 2015
Be Reactive! at Functional and Reactive Programmers Group, Kaiserslautern March 31 2015
Be Reactive! at Functional and Reactive Programmers Group, Kaiserslautern March 31 2015
Be Reactive! at Functional and Reactive Programmers Group, Kaiserslautern March 31 2015
Be Reactive! at Functional and Reactive Programmers Group, Kaiserslautern March 31 2015
Be Reactive! at Functional and Reactive Programmers Group, Kaiserslautern March 31 2015
Upcoming SlideShare
Loading in …5
×

Be Reactive! at Functional and Reactive Programmers Group, Kaiserslautern March 31 2015

600 views

Published on

If you deal with distributed, fault-tolerant systems, you've sooner or later come across the "Reactive Manifesto" meet (if you haven't so far, you have now: "http://www.reactivemanifesto.org/"). But, as befits a manifesto, it sets out a programmatic vision, without providing detailed explanations and guidelines for implementation.

In this talk I discuss the reactive traits, and try to bring it down a level to technical properties: What is Reactive code, how do I put the principles into practice, and what are anti-patterns, which are to be avoided in reactive systems? And what does this all have to do with functional programming?

The event:
http://www.meetup.com/Reactive-and-Functional-Programming-Meetup-Pfalz/events/220455257/

Sources:
* JVM Implementation Challenges ("Threads are passé"): https://www.jfokus.se/jfokus15/preso/JVMChallenges.pdf

* The Problem With Threads: http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

* Life Beyond Distributed Transactions
PDF: https://github.com/papers-we-love/papers-we-love/blob/master/distributed_systems/life-beyoud-distributed-transactions-an-apostates-opinion.pdf?raw=true
PowerPoint: http://blogs.msdn.com/b/pathelland/archive/2007/11/25/presentation-of-life-beyond-distributed-transactions-an-apostate-s-opinion-at-teched-emea-at-barcelona.aspx (Link unten auf der Seite)

* Java Application Servers Are Dead:
Slides: http://de.slideshare.net/ewolff/java-application-servers-are-dead
Artikel: http://jaxenter.com/java-application-servers-dead-1-111928.html und http://jaxenter.com/java-application-servers-dead-112186.html

Published in: Software
no profile picture user

  • Be the first to comment

Be Reactive! at Functional and Reactive Programmers Group, Kaiserslautern March 31 2015

  1. 1. Be Reactive!
  2. 2. What’s happening?
  3. 3. Be Reactive! SUG KL March 2015 Elastic • Ability to scale, but also • be efficient, leverage modern multi- / many-core hardware • Scale up and down - Clusters need to support joining and leaving of nodes • To scale, every part must scale - no single point of failure, no contention 7
  4. 4. Be Reactive! SUG KL March 2015 Resilient • Failure is embraced as a regular state in the system • Resilience is a first-class concept in your software • Failure is detected, isolated, and managed • Applications can recover from failure of parts (self-heal) 8
  5. 5. Be Reactive! SUG KL March 2015 Before we get to message-driven • Let’s talk about • Multi-Threading • I/O • Distribution • Deployment 9
  6. 6. Threads vs. task level concurrency
  7. 7. Be Reactive! SUG KL March 2015 A supposedly great idea • Threads are • lightweight processes • easier programming model, no IPC 11
  8. 8. Be Reactive! SUG KL March 2015 Lightweight? 12 Slide stolen from John Rose, Java VM Architect, JFokus, Stockholm, February 2015
  9. 9. Be Reactive! SUG KL March 2015 The problem with Threads 13 They discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism. Threads, as a model of computation, are wildly nondeterministic, and the job of the programmer becomes one of pruning that nondeterminism.
  10. 10. + Let’s talk about Multi-Threading
  11. 11. Be Reactive! SUG KL March 2015 Threads • not efficient • memory consumption • cost for context switch • shared memory bad for modern NUMA architectures • locks lead to contention
 • not a good programming model • shared mutual state is difficult to reason about 15
  12. 12. Be Reactive! SUG KL March 2015 Tasks Better • task level (sub-thread) concurrency • share nothing approach • # threads ~ # of cores • Example: Actors, Play Actions 16
  13. 13. Blocking vs. non-blocking I/O
  14. 14. Be Reactive! SUG KL March 2015 High concurrency matters 18 But there’s one thing we can all agree on: At high levels of concurrency (thousands of connections) your server needs to go to asynchronous non-blocking. [..] any part of your server code blocks you’re going to need a thread. And at these levels of concurrency, you can’t go creating threads for every connection. From https://strongloop.com/strongblog/node-js-is-faster-than-java/
  15. 15. Be Reactive! SUG KL March 2015 Blocking I/O, Thread-per-request 19 From https://strongloop.com/strongblog/node-js-is-faster-than-java/
  16. 16. Be Reactive! SUG KL March 2015 Non-blocking I/O 20 Note: Single Thread is crazy! What about your other cores?
  17. 17. Be Reactive! SUG KL March 2015 Non-blocking 21 For task level (sub-thread level) concurrency • each thread is responsible for n tasks • and that n might be pretty big You don’t want to block such a thread with blocking I/O What if you must? Separate!
  18. 18. Distributed Transactions vs. EC
  19. 19. Be Reactive! SUG KL March 2015 Life beyond Distributed Transactions 23 In general, application developers simply do not implement large scalable applications assuming distributed transactions. When they attempt to use distributed transactions, the projects founder because the performance costs and fragility make them impractical. [..] Instead, applications are built using different techniques which do not provide the same transactional guarantees but still meet the needs of their businesses.
  20. 20. 24 Want Almost-Infinite Scaling
 • More of everything… Year by year, bigger and bigger • If it fits on your machines, multiply by 10, if that fits, multiply by 1000… • Strive to scale almost linearly (N log N for some big log). Assumptions
 (Don’t Have to Prove These… Just Plain Believe Them) Grown-Ups Don’t Use Distributed Transactions •The apps using distributed transactions become too fragile… • Let’s just consider local transactions. ! Multiple disjoint scopes of serializability Want Scale-Agnostic Apps
 • Two layers to the application: 
 scale-agnostic and scale-aware • Consider scale-agnostic API Scale Agnostic Code Scale-Aware-Code Application Upper Layer Lower Layer Scale Agnostic API
  21. 21. Be Reactive! SUG KL March 2015 Distributed Transactions 25 Distributed Transactions („2PC“) are a source of unnecessary failure and of contention. It can usually be avoided. In the aforementioned paper by Pat Helland, he shows how to use local transactions and at-least-once delivery instead. The data storage landscape is changing, moving towards event sourcing and immutability. This is a great match for reactive systems.
  22. 22. App Servers vs. Containerless
  23. 23. Be Reactive! SUG KL March 2015 27
  24. 24. Be Reactive! SUG KL March 2015 28
  25. 25. Be Reactive! SUG KL March 2015 Java EE Application Servers 29 Servlet API was developed for thread-per-request, synchronous I/O. Application servers are not of much use anyway, nobody uses them as containers for multiple applications. Go containerless.
  26. 26. Summary
  27. 27. Be Reactive! SUG KL March 2015 Checklist 31 If • Threads are the smallest unit of concurrency in your code, or • You use blocking I/O (without clear separation), or • You use 2-phase-commit across systems, or • You run in a Java EE Application Server Then your application is not reactive.
  28. 28. Be Reactive! SUG KL March 2015 Want list 32 • Task-level (sub-thread level) concurrency • Non-blocking I/O • Distribution • Containerless Bonus: A simple, unified programming model
  29. 29. .. gives you all that
  30. 30. Be Reactive! SUG KL March 2015 Message-Driven • Loosely coupled architecture, easier to extend, maintain, evolve • Asynchronous and non-blocking • Concurrent by design, immutable state • Lower latency and higher throughput 34
  31. 31. Go Reactive! Swisscom March 2015 37
  32. 32. Go Reactive! Swisscom March 2015 • We want to be asynchronous and non-blocking • We need to ensure that our data is protected without locks • We want to compose individual tasks into broader business logic • Functional programming is critical to meeting these needs • Declarative • Immutable • Referentially transparent • Pure functions that only have inputs and outputs 38 Functional programming is key
  33. 33. Be Reactive! SUG KL March 2015 Where can I find that? 39
  34. 34. Be Reactive! SUG KL March 2015 40 Want to learn more? http://www.typesafe.com http://go.typesafe.com Questions? lutz.huehnken@typesafe.com @lutzhuehnken on Twitter

×