1.
Be Reactive!

2.
What’s happening?

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.
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.
Be Reactive! SUG KL March 2015
Before we get to message-driven
• Let’s talk about
• Multi-Threading
• I/O
• Distribution
• Deployment
9

6.
Threads vs. task level concurrency

7.
Be Reactive! SUG KL March 2015
A supposedly great idea
• Threads are
• lightweight processes
• easier programming model, no IPC
11

8.
Be Reactive! SUG KL March 2015
Lightweight?
12
Slide stolen from John Rose, Java VM Architect, JFokus, Stockholm, February 2015

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.
+
Let’s talk about
Multi-Threading

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.
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.
Blocking vs. non-blocking I/O

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.
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.
Be Reactive! SUG KL March 2015
Non-blocking I/O
20
Note: Single Thread is crazy! What about your other cores?

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.
Distributed Transactions vs. EC

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.
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.
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.
App Servers vs. Containerless

23.
Be Reactive! SUG KL March 2015 27

24.
Be Reactive! SUG KL March 2015 28

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.
Summary

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.
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.
.. gives you all that

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.
Go Reactive! Swisscom March 2015 37

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.
Be Reactive! SUG KL March 2015
Where can I find that?
39

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