Upload
lutz-huehnken
View
86
Download
3
Tags:
Embed Size (px)
Citation preview
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
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
Be Reactive! SUG KL March 2015
Before we get to message-driven
• Let’s talk about • Multi-Threading • I/O • Distribution • Deployment
9
Be Reactive! SUG KL March 2015
A supposedly great idea
• Threads are • lightweight processes • easier programming model, no IPC
11
Be Reactive! SUG KL March 2015
Lightweight?
12
Slide stolen from John Rose, Java VM Architect, JFokus, Stockholm, February 2015
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.
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
Be Reactive! SUG KL March 2015
Tasks
Better • task level (sub-thread) concurrency • share nothing approach • # threads ~ # of cores
• Example: Actors, Play Actions
16
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/
Be Reactive! SUG KL March 2015
Blocking I/O, Thread-per-request
19
From https://strongloop.com/strongblog/node-js-is-faster-than-java/
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 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!
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.
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
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.
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.
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.
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
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
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
Be Reactive! SUG KL March 2015 40
Want to learn more? http://www.typesafe.com http://go.typesafe.com
Questions? [email protected]
@lutzhuehnken on Twitter