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

Be Reactive!

What’s happening?

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


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


Before we get to message-driven

• Let’s talk about • Multi-Threading • I/O • Distribution • Deployment

9

Threads vs. task level concurrency


A supposedly great idea

• Threads are • lightweight processes • easier programming model, no IPC

11


Lightweight?

12

Slide stolen from John Rose, Java VM Architect, JFokus, Stockholm, February 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.

+

Let’s talk about Multi-Threading


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


Tasks

Better • task level (sub-thread) concurrency • share nothing approach • # threads ~ # of cores

• Example: Actors, Play Actions

16

Blocking vs. non-blocking I/O


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/

https://strongloop.com/strongblog/node-js-is-faster-than-java/


Blocking I/O, Thread-per-request

19

From https://strongloop.com/strongblog/node-js-is-faster-than-java/

https://strongloop.com/strongblog/node-js-is-faster-than-java/


Non-blocking I/O

20

Note: Single Thread is crazy! What about your other cores?


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!

Distributed Transactions vs. EC


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.

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


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.

App Servers vs. Containerless

Be Reactive! SUG KL March 2015 27



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.

Summary


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.


Want list

32

• Task-level (sub-thread level) concurrency • Non-blocking I/O • Distribution • Containerless

Bonus: A simple, unified programming model

.. gives you all that


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

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


Where can I find that?

39


Want to learn more? http://www.typesafe.com http://go.typesafe.com

Questions? [email protected]

@lutzhuehnken on Twitter

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

Software

javabe reactive

ipc11be reactive

about15be reactive

contention7be reactive

ecbe reactive

nonblocking iobe reactive

single thread

nonblocking io20note