SlideShare a Scribd company logo

Akka in 100 slides or less

D
Derek Wyatt

The document introduces Akka, a framework for building concurrent applications using actors, which encapsulate state and process messages asynchronously. It explains the benefits of using actors for managing concurrency, fault tolerance, and creating resilient, scalable systems by maintaining service decoupling and handling message delivery failures. Additionally, it emphasizes the use of composable futures to avoid callback hell and improve readability in asynchronous programming.

Software
1 of 93
Downloaded 117 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
Akka in 100 slides or less Derek Wyatt Twitter: @derekwyatt Email: derek@derekwyatt.orgAugust 2015
Akka is Concurrency
Akka is Concurrency Actors: Living objects with concurrent context “I am for you, Alrik of Valt.”
Akka is Concurrency Actors: Living objects with concurrent context Futures: These aren’t Java’s Futures val  futureData  =  for  {      response  <-­‐  httpGet(…)      query  =  response.body.as[Query]      (img,  text)  <-­‐  imageQuery(query)      scaledImg  <-­‐  scaleImg(img)   }  yield  NewPostData(text,  scaledImg) “I am for you, Alrik of Valt.”
Akka is Concurrency Actors: Living objects with concurrent context Futures: These aren’t Java’s Futures val  futureData  =  for  {      response  <-­‐  httpGet(…)      query  =  response.body.as[Query]      (img,  text)  <-­‐  imageQuery(query)      scaledImg  <-­‐  scaleImg(img)   }  yield  NewPostData(text,  scaledImg) Asynchronous Asynchronous Asynchronous Asynchronous “I am for you, Alrik of Valt.”
Akka is Concurrency Actors: Living objects with concurrent context Futures: These aren’t Java’s Futures val  futureData  =  for  {      response  <-­‐  httpGet(…)      query  =  response.body.as[Query]      (img,  text)  <-­‐  imageQuery(query)      scaledImg  <-­‐  scaleImg(img)   }  yield  NewPostData(text,  scaledImg) Asynchronous Asynchronous Asynchronous Asynchronous Streams: Async Non-Blocking and Back-Pressured Source Sink Demand Supply Http too… “I am for you, Alrik of Valt.”
Akka is Concurrency Actors: Living objects with concurrent context Futures: These aren’t Java’s Futures val  futureData  =  for  {      response  <-­‐  httpGet(…)      query  =  response.body.as[Query]      (img,  text)  <-­‐  imageQuery(query)      scaledImg  <-­‐  scaleImg(img)   }  yield  NewPostData(text,  scaledImg) Asynchronous Asynchronous Asynchronous Asynchronous Streams: Async Non-Blocking and Back-Pressured Source Sink Demand Supply Http too… “I am for you, Alrik of Valt.” Support for Scala and Java (but use Scala, cuz…)
Actors: Concurrency in Isolation
Actors: Concurrency in Isolation count: _ alert: _ score: _
Actors: Concurrency in Isolation count: 2 alert: Y score: 16 count: 4 alert: N score: 2 count: 33 alert: G score: 71 count: 13 alert: G score: 12 count: 7 alert: X score: 5 count: 8 alert: N score: 11 count: 2 alert: I score: 14 count: 87 alert: G score: 0 count: 1 alert: B score: 6 count: 7 alert: W score: 32 count: 7 alert: O score: 19 count: 4 alert: G score: 99 count: _ alert: _ score: _ ✗Construct as many as you’d like
Actors: Concurrency in Isolation count: 2 alert: Y score: 16 count: 4 alert: N score: 2 count: 33 alert: G score: 71 count: 13 alert: G score: 12 count: 7 alert: X score: 5 count: 8 alert: N score: 11 count: 2 alert: I score: 14 count: 87 alert: G score: 0 count: 1 alert: B score: 6 count: 7 alert: W score: 32 count: 7 alert: O score: 19 count: 4 alert: G score: 99 count: _ alert: _ score: _ ✗Construct as many as you’d like ✗Each one encapsulates its own state
Actors: Concurrency in Isolation count: 2 alert: Y score: 16 count: 4 alert: N score: 2 count: 33 alert: G score: 71 count: 13 alert: G score: 12 count: 7 alert: X score: 5 count: 8 alert: N score: 11 count: 2 alert: I score: 14 count: 87 alert: G score: 0 count: 1 alert: B score: 6 count: 7 alert: W score: 32 count: 7 alert: O score: 19 count: 4 alert: G score: 99 Thread Thread count: _ alert: _ score: _ ✗Construct as many as you’d like ✗Each one encapsulates its own state ✗They all (can) share the same thread pool
Actors: Concurrency in Isolation count: 2 alert: Y score: 16 count: 4 alert: N score: 2 count: 33 alert: G score: 71 count: 13 alert: G score: 12 count: 7 alert: X score: 5 count: 8 alert: N score: 11 count: 2 alert: I score: 14 count: 87 alert: G score: 0 count: 1 alert: B score: 6 count: 7 alert: W score: 32 count: 7 alert: O score: 19 count: 4 alert: G score: 99 Thread Thread count: _ alert: _ score: _ ✗Construct as many as you’d like ✗Each one encapsulates its own state ✗They all (can) share the same thread pool ✗They cannot interfere with each other
Actors: Concurrency in Isolation count: 2 alert: Y score: 16 count: 4 alert: N score: 2 count: 33 alert: G score: 71 count: 8 alert: N score: 11 count: 2 alert: I score: 14 count: 87 alert: G score: 0 count: 1 alert: B score: 6 count: 7 alert: W score: 32 count: 7 alert: O score: 19 count: 4 alert: G score: 99 Thread Thread count: _ alert: _ score: _ ✗Construct as many as you’d like ✗Each one encapsulates its own state ✗They all (can) share the same thread pool ✗They cannot interfere with each other ✗Their life-cycles are entirely under your control
It’s all about the messages!
It’s all about the messages! Actors have no public methods⦿ A
It’s all about the messages! Actors have no public methods⦿ Actors have no publicly accessible data⦿ A B
It’s all about the messages! Actors have no public methods⦿ Actors have no publicly accessible data⦿ You cannot communicate with Actors Synchronously ⦿ A B
It’s all about the messages! Actors have no public methods⦿ Actors have no publicly accessible data⦿ You cannot communicate with Actors Synchronously ⦿ The only way to talk to them is with Messages ⦿ A B hey
It’s all about the messages! Actors have no public methods⦿ Actors have no publicly accessible data⦿ You cannot communicate with Actors Synchronously ⦿ The only way to talk to them is with Messages ⦿ The only way to access their data is with Messages ⦿ A B 83
It’s all about the messages! Actors have no public methods⦿ Actors have no publicly accessible data⦿ You cannot communicate with Actors Synchronously ⦿ The only way to talk to them is with Messages ⦿ The only way to access their data is with Messages ⦿ Messages can (and should) carry conversational state ⦿ A B A
It’s all about the messages! Actors have no public methods⦿ Actors have no publicly accessible data⦿ You cannot communicate with Actors Synchronously ⦿ The only way to talk to them is with Messages ⦿ The only way to access their data is with Messages ⦿ Messages can (and should) carry conversational state ⦿ A B A Done(a,b,c)
Actors are Fault Tolerant Parent Child Child Child Mailbox Mailbox Mailbox Mailbox
Actors are Fault Tolerant Actors supervise their children Parent Child Child Child Mailbox Mailbox Mailbox Mailbox
Actors are Fault Tolerant Actors supervise their children Failed Actors are restarted (or stopped, or resumed, or escalated) by their supervisors Parent Child Child Child Mailbox Mailbox Mailbox Mailbox
Actors are Fault Tolerant Actors supervise their children Failed Actors are restarted (or stopped, or resumed, or escalated) by their supervisors Restarted Actors are given a fresh state Parent Child Child Child Mailbox Mailbox Mailbox Mailbox
Actors are Fault Tolerant Actors supervise their children Failed Actors are restarted (or stopped, or resumed, or escalated) by their supervisors Restarted Actors are given a fresh state The message they were processing is lost Parent Child Child Child Mailbox Mailbox Mailbox Mailbox
Actors are Fault Tolerant Actors supervise their children Failed Actors are restarted (or stopped, or resumed, or escalated) by their supervisors Restarted Actors are given a fresh state The message they were processing is lost Parent Child Child Mailbox Mailbox Mailbox Mailbox Child
Death is Actionable Parent Child ChildChild Deathwatch Mailbox
Death is Actionable ❉ Restarting is invisible to outsiders… ❉ …But Actor Death is visible ❉ Deathwatch lets Actors react to death, such as to recreate a child Parent Child ChildChild Deathwatch Mailbox
Death is Actionable ❉ Restarting is invisible to outsiders… ❉ …But Actor Death is visible ❉ Deathwatch lets Actors react to death, such as to recreate a child Parent ChildChildChild Deathwatch Mailbox
Death is Actionable ❉ Restarting is invisible to outsiders… ❉ …But Actor Death is visible ❉ Deathwatch lets Actors react to death, such as to recreate a child Parent ChildChildChild Deathwatch Mailbox ❉ … Or a transaction is complete, or it’s time to shut down, or a current stage of processing is finished, or…
Death is Actionable ❉ Restarting is invisible to outsiders… ❉ …But Actor Death is visible ❉ Deathwatch lets Actors react to death, such as to recreate a child Parent ChildChildChild Deathwatch Mailbox ❉ Remember that this is death, so the mailbox contents are lost ❉ … Or a transaction is complete, or it’s time to shut down, or a current stage of processing is finished, or…
So, why would I use Actors?
So, why would I use Actors? ✗Actors help you manage concurrency Reasoning
So, why would I use Actors? ✗Actors help you manage concurrency ✗Actors let you implement services within your system Reasoning Service decoupling
So, why would I use Actors? ✗Actors help you manage concurrency ✗Actors let you implement services within your system ✗Actors let you design an entirely asynchronous system Reasoning Service decoupling Capacity and Throughput
So, why would I use Actors? ✗Actors help you manage concurrency ✗Actors let you implement services within your system ✗Actors let you design an entirely asynchronous system ✗Actors let you define the resiliency of your applications Reasoning Service decoupling Capacity and Throughput Fault Tolerance
So, why would I use Actors? ✗Actors help you manage concurrency ✗Actors let you implement services within your system ✗Actors let you design an entirely asynchronous system ✗Actors let you define the resiliency of your applications ✗ Eventual consistency, and message delivery failure are realities that Actors help you deal with throughout your code Reasoning Service decoupling Capacity and Throughput Fault Tolerance Massive Scale Self Healing
So, why would I use Actors? ✗Actors help you manage concurrency ✗Actors let you implement services within your system ✗Actors let you design an entirely asynchronous system ✗Actors let you define the resiliency of your applications ✗ Eventual consistency, and message delivery failure are realities that Actors help you deal with throughout your code ✗ Most importantly, Actors help you think about the problem differently and express your solutions more creatively Reasoning Service decoupling Capacity and Throughput Fault Tolerance Massive Scale Self Healing Sanity, Clarity, and Reasonability!!
“Functional” Futures
“Functional” Futures ◎ A Future is just a value, but not yet…
“Functional” Futures ◎ A Future is just a value, but not yet… ◎ java.util.concurrent.Future is a bad Future. Akka gave us Futures that compose!
“Functional” Futures ◎ A Future is just a value, but not yet… ◎ java.util.concurrent.Future is a bad Future. Akka gave us Futures that compose! ◎ Composable Futures let us abstract over Future values, rather than wait for them for {
“Functional” Futures ◎ A Future is just a value, but not yet… ◎ java.util.concurrent.Future is a bad Future. Akka gave us Futures that compose! ◎ Composable Futures let us abstract over Future values, rather than wait for them for { a <- futureA() futureA()
futureB(a) “Functional” Futures ◎ A Future is just a value, but not yet… ◎ java.util.concurrent.Future is a bad Future. Akka gave us Futures that compose! ◎ Composable Futures let us abstract over Future values, rather than wait for them for { a <- futureA() b <- futureB(a) futureA()
futureC(a,b) futureB(a) “Functional” Futures ◎ A Future is just a value, but not yet… ◎ java.util.concurrent.Future is a bad Future. Akka gave us Futures that compose! ◎ Composable Futures let us abstract over Future values, rather than wait for them for { a <- futureA() b <- futureB(a) c <- futureC(a,b) futureA()
futureC(a,b) futureB(a) “Functional” Futures ◎ A Future is just a value, but not yet… ◎ java.util.concurrent.Future is a bad Future. Akka gave us Futures that compose! ◎ Composable Futures let us abstract over Future values, rather than wait for them for { a <- futureA() b <- futureB(a) c <- futureC(a,b) } yield c futureA() One composed Future
futureC(a,b) futureB(a) “Functional” Futures ◎ A Future is just a value, but not yet… ◎ java.util.concurrent.Future is a bad Future. Akka gave us Futures that compose! ◎ Composable Futures let us abstract over Future values, rather than wait for them for { a <- futureA() b <- futureB(a) c <- futureC(a,b) } yield c futureA() ◎ Futures compose as Monads compose, which makes them “standard” functional abstractions, and that’s a powerful thing One composed Future
Abolish Callback Hell
Abolish Callback Hell public void restHandler(RESTRequest req) { idservice.validate(req.userInfo, new Callback<ValidateResult>() { public void run(ValidateResult result) { if (result.isValid) { db.getProfile(req.userId, new Callback<UserProfile>() { public void run(UserProfile profile) { picServer.get(profile.pic1, new Callback<Pic>() { public void run(Pic p1) { picServer.get(profile.pic2, new Callback<Pic>() { public void run(Pic p2) { picServer.get(profile.pic3, new Callback<Pic>() { public void run(Pic p3) { picServer.get(profile.pic4, new Callback<Pic>() { public void run(Pic p4) { picServer.get(profile.pic5, new Callback<Pic>() { public void run(Pic p5) { twitterServer.getRecentActivity(req.userInfo, new Callback<TwitterActivity>() { public void run(TwitterActivity activity) { req.sendResponse(pic1, pic2, pic3, pic4, pic5, activity) } } } } } } } }
Abolish Callback Hell public void restHandler(RESTRequest req) { idservice.validate(req.userInfo, new Callback<ValidateResult>() { public void run(ValidateResult result) { if (result.isValid) { db.getProfile(req.userId, new Callback<UserProfile>() { public void run(UserProfile profile) { picServer.get(profile.pic1, new Callback<Pic>() { public void run(Pic p1) { picServer.get(profile.pic2, new Callback<Pic>() { public void run(Pic p2) { picServer.get(profile.pic3, new Callback<Pic>() { public void run(Pic p3) { picServer.get(profile.pic4, new Callback<Pic>() { public void run(Pic p4) { picServer.get(profile.pic5, new Callback<Pic>() { public void run(Pic p5) { twitterServer.getRecentActivity(req.userInfo, new Callback<TwitterActivity>() { public void run(TwitterActivity activity) { req.sendResponse(pic1, pic2, pic3, pic4, pic5, activity) } } } } } } } } We didn’t handle errors We didn’t handle timeouts It’s not necessarily Threadsafe It’s incredibly hard to read
Compose your Futures implicit val _timeout = Timeout(30.seconds) def restHandler(req: RESTRequest): Future[RESTResponse] = { val resp = for { validity <- idService.validate(req.userInfo) if validity.isValid profile <- db.getProfile(req.userId) pic1 <- picServer.get(profile.pic1) pic2 <- picServer.get(profile.pic2) pic3 <- picServer.get(profile.pic3) pic4 <- picServer.get(profile.pic4) pic5 <- picServer.get(profile.pic5) activity <- twitterServer.getRecentActivity(req.userInfo) } yield SuccessfulResponse(pic1, pic2, pic3, pic4, pic5, activity) resp recover { e: Throwable => FailedResponse(e) } }
Compose your Futures implicit val _timeout = Timeout(30.seconds) def restHandler(req: RESTRequest): Future[RESTResponse] = { val resp = for { validity <- idService.validate(req.userInfo) if validity.isValid profile <- db.getProfile(req.userId) pic1 <- picServer.get(profile.pic1) pic2 <- picServer.get(profile.pic2) pic3 <- picServer.get(profile.pic3) pic4 <- picServer.get(profile.pic4) pic5 <- picServer.get(profile.pic5) activity <- twitterServer.getRecentActivity(req.userInfo) } yield SuccessfulResponse(pic1, pic2, pic3, pic4, pic5, activity) resp recover { e: Throwable => FailedResponse(e) } } Errors have been handled Timeouts have been handled It’s (probably) Threadsafe I didn’t have to shrink the font
So why would I use Futures?
So why would I use Futures? Asynchronous programming is still hard⦿
So why would I use Futures? Asynchronous programming is still hard⦿ Programming synchronously isn’t a reasonable response⦿ Thread starvation timeouts capacity issues thread thrashing
So why would I use Futures? Asynchronous programming is still hard⦿ Programming synchronously isn’t a reasonable response⦿ Scala Futures embody asynchronous values⦿ Thread starvation timeouts capacity issues thread thrashing Everything is a value
So why would I use Futures? Asynchronous programming is still hard⦿ Programming synchronously isn’t a reasonable response⦿ Scala Futures embody asynchronous values⦿ They let us express composed asynchronous computation⦿ Thread starvation timeouts capacity issues thread thrashing Everything is a value Less Side Effects
So why would I use Futures? Asynchronous programming is still hard⦿ Programming synchronously isn’t a reasonable response⦿ Scala Futures embody asynchronous values⦿ They let us express composed asynchronous computation⦿ Futures let us propagate errors and recover from them⦿ Thread starvation timeouts capacity issues thread thrashing Everything is a value Less Side Effects Graceful Failure Resiliency
So why would I use Futures? Asynchronous programming is still hard⦿ Programming synchronously isn’t a reasonable response⦿ Scala Futures embody asynchronous values⦿ They let us express composed asynchronous computation⦿ Futures let us propagate errors and recover from them⦿ Asynchronous programming has always been possible but Futures now make it much more viable ⦿ Thread starvation timeouts capacity issues thread thrashing Everything is a value Less Side Effects Graceful Failure Resiliency
Operating on Data Streams
Operating on Data Streams ❉ In the real world, we communicate with things Networks Disks Databases Services Slower Algorithms
Operating on Data Streams ❉ In the real world, we communicate with things Networks Disks Databases Services Slower Algorithms ❉ Polling sucks. We live in a real time world.
Operating on Data Streams ❉ In the real world, we communicate with things Networks Disks Databases Services Slower Algorithms ❉ Polling sucks. We live in a real time world. ❉ Eventing can be hard, since it doesn’t compose
Operating on Data Streams ❉ In the real world, we communicate with things Networks Disks Databases Services Slower Algorithms ❉ Polling sucks. We live in a real time world. ❉ Eventing can be hard, since it doesn’t compose ❉ Throttling is a real problem we never address
Operating on Data Streams ❉ In the real world, we communicate with things Networks Disks Databases Services Slower Algorithms ❉ Polling sucks. We live in a real time world. ❉ Eventing can be hard, since it doesn’t compose ❉ Throttling is a real problem we never address ❉ Akka Streams help us solve all of these problems
Operating on Data Streams ❉ In the real world, we communicate with things Networks Disks Databases Services Slower Algorithms ❉ Polling sucks. We live in a real time world. ❉ Eventing can be hard, since it doesn’t compose ❉ Throttling is a real problem we never address ❉ Akka Streams help us solve all of these problems Source Transformation Flow Transformation Flow Sink Demand Supply
BackPressure is key Source Sink
BackPressure is key ◎ Fast producers can kill; we only have so much RAM Source Sink
BackPressure is key ◎ Fast producers can kill; we only have so much RAM ◎ Producers can’t be artificially slow just to be nice Source Sink
BackPressure is key ◎ Fast producers can kill; we only have so much RAM ◎ Producers can’t be artificially slow just to be nice ◎ Consumers signal demand, Producers signal supply Source Sink
BackPressure is key ◎ Fast producers can kill; we only have so much RAM ◎ Producers can’t be artificially slow just to be nice ◎ Consumers signal demand, Producers signal supply ◎ When a consumer is slow, it signals no demand Source Sink
BackPressure is key ◎ Fast producers can kill; we only have so much RAM ◎ Producers can’t be artificially slow just to be nice ◎ Consumers signal demand, Producers signal supply ◎ When a consumer is slow, it signals no demand ◎ When a producer is slow, it doesn’t supply Source Sink
BackPressure is key ◎ Fast producers can kill; we only have so much RAM ◎ Producers can’t be artificially slow just to be nice ◎ Consumers signal demand, Producers signal supply ◎ When a consumer is slow, it signals no demand ◎ When a producer is slow, it doesn’t supply Source Sink Supply
Composable Binary Protocols
Composable Binary Protocols Framer ByteString ByteString BidiFlow Serializer Object ByteString BidiFlow Chunker ByteString ByteString BidiFlow
Composable Binary Protocols Framer ByteString ByteString BidiFlow Serializer Object ByteString BidiFlow Chunker ByteString ByteString BidiFlow Application Object Object Source Sink Network ByteString ByteString Source Sink BidiFlow ByteStringObject
Composable Binary Protocols Framer ByteString ByteString BidiFlow Serializer Object ByteString BidiFlow Chunker ByteString ByteString BidiFlow Application Object Object Source Sink Network ByteString ByteString Source Sink BidiFlow ByteStringObject ✗Entirely reusable components that fit in any BiDirectional Flow
Composable Binary Protocols Framer ByteString ByteString BidiFlow Serializer Object ByteString BidiFlow Chunker ByteString ByteString BidiFlow Application Object Object Source Sink Network ByteString ByteString Source Sink BidiFlow ByteStringObject ✗Entirely reusable components that fit in any BiDirectional Flow ✗Type safe (or as type safe as byte string marshaling gets)
Composable Binary Protocols Framer ByteString ByteString BidiFlow Serializer Object ByteString BidiFlow Chunker ByteString ByteString BidiFlow Application Object Object Source Sink Network ByteString ByteString Source Sink BidiFlow ByteStringObject ✗Entirely reusable components that fit in any BiDirectional Flow ✗Type safe (or as type safe as byte string marshaling gets) ✗Entirely back pressured from end to end
Composable Binary Protocols Framer ByteString ByteString BidiFlow Serializer Object ByteString BidiFlow Chunker ByteString ByteString BidiFlow Application Object Object Source Sink Network ByteString ByteString Source Sink BidiFlow ByteStringObject ✗Entirely reusable components that fit in any BiDirectional Flow ✗Type safe (or as type safe as byte string marshaling gets) ✗Entirely back pressured from end to end ✗100% event driven and reactive Realtime Speeds No Blocking Threads Natural Throttling graceful performance degradationNot a Crash
Why Would I use Streams?
Why Would I use Streams? Streaming is (probably) the crown jewel of Akka’s offering (but it’s a tough call)
Why Would I use Streams? Streaming is (probably) the crown jewel of Akka’s offering The need to respond to backpressure is real and we never do it ! (but it’s a tough call)
Why Would I use Streams? Streaming is (probably) the crown jewel of Akka’s offering The need to respond to backpressure is real and we never do it The need to treat our threads with respect is important ! ! (but it’s a tough call)
Why Would I use Streams? Streaming is (probably) the crown jewel of Akka’s offering The need to respond to backpressure is real and we never do it The need to treat our threads with respect is important The need to be reactive and fast is vital to the user experience ! ! ! (but it’s a tough call)
Why Would I use Streams? Streaming is (probably) the crown jewel of Akka’s offering The need to respond to backpressure is real and we never do it The need to treat our threads with respect is important The need to be reactive and fast is vital to the user experience Streams give us all of this and let us use our hardware to its fullest ! ! ! !!! (but it’s a tough call)
Akka from 20k feetAkka from 20k feet
Akka from 20k feetAkka from 20k feet Actors! Actors! Live Objects Supervised Asynchronous Message Passing Services State Machines Network Ready
Akka from 20k feetAkka from 20k feet Actors! Actors! Futures! Futures! Live Objects Supervised Asynchronous Message Passing Services State Machines Network Ready Composable Values Reactive Monadic Immutable Threadsafe Work Well with Actors
Akka from 20k feetAkka from 20k feet Actors! Actors! Futures! Futures! Streams! Streams! Live Objects Supervised Asynchronous Message Passing Services State Machines Network Ready Composable Values Reactive Monadic Immutable Threadsafe Work Well with Actors BackPressured Composable Reusable Event Driven Flexible Lots of Activity and Support Work with Futures and Actors
Go Get AKKA!Go Get AKKA! Website: http://akka.io Scala Reference: http://doc.akka.io/docs/akka/current/scala.html Java Reference: http://doc.akka.io/docs/akka/current/java.html Streams Reference: http://doc.akka.io/docs/akka-stream-and-http-experimental/current/scala.html Derek Wyatt Twitter: @derekwyatt Email: derek@derekwyatt.orgAugust 2015

More Related Content

PDF
Introducing Akka
Jonas Bonér
 
PPTX
Akka Actor presentation
Gene Chang
 
PDF
Building Reactive Systems with Akka (in Java 8 or Scala)
Jonas Bonér
 
PDF
Akka - A Brief Intro
Thomas Lockney
 
PDF
Zen of Akka
Konrad Malawski
 
KEY
Introduction to Actor Model and Akka
Yung-Lin Ho
 
PDF
Introduction to Akka
Johan Andrén
 
PDF
Effective Scala (SoftShake 2013)
mircodotta
 
Introducing Akka
Jonas Bonér
 
Akka Actor presentation
Gene Chang
 
Building Reactive Systems with Akka (in Java 8 or Scala)
Jonas Bonér
 
Akka - A Brief Intro
Thomas Lockney
 
Zen of Akka
Konrad Malawski
 
Introduction to Actor Model and Akka
Yung-Lin Ho
 
Introduction to Akka
Johan Andrén
 
Effective Scala (SoftShake 2013)
mircodotta
 

Viewers also liked (19)

PDF
Akka in Production - ScalaDays 2015
Evan Chan
 
PDF
Effective Scala (JavaDay Riga 2013)
mircodotta
 
PDF
Akka cluster overview at 010dev
Roland Kuhn
 
PPTX
Akka Fundamentals
Michael Kendra
 
PDF
Akka: Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Ac...
Jonas Bonér
 
PDF
Event-sourced architectures with Akka
Sander Mak (@Sander_Mak)
 
PPTX
Actor-based concurrency and Akka Fundamentals
Ngoc Dao
 
PPTX
Go lang - What is that thing?
Ezequiel Maraschio
 
PDF
Introduction to the Actor Model
BoldRadius Solutions
 
PPTX
Akka framework
mitesh_sharma
 
KEY
Actors and Threads
mperham
 
PPTX
Functional Programming and Concurrency Patterns in Scala
kellogh
 
PDF
Effective Scala: Programming Patterns
Vasil Remeniuk
 
PPTX
Scala’s implicits
Pablo Francisco Pérez Hidalgo
 
PDF
Go Lang Tutorial
Wei-Ning Huang
 
PDF
Real-World Scala Design Patterns
NLJUG
 
PDF
Scala Implicits - Not to be feared
Derek Wyatt
 
PDF
Akka streams
mircodotta
 
PPTX
Mongo db - How we use Go and MongoDB by Sam Helman
Hakka Labs
 
Akka in Production - ScalaDays 2015
Evan Chan
 
Effective Scala (JavaDay Riga 2013)
mircodotta
 
Akka cluster overview at 010dev
Roland Kuhn
 
Akka Fundamentals
Michael Kendra
 
Akka: Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Ac...
Jonas Bonér
 
Event-sourced architectures with Akka
Sander Mak (@Sander_Mak)
 
Actor-based concurrency and Akka Fundamentals
Ngoc Dao
 
Go lang - What is that thing?
Ezequiel Maraschio
 
Introduction to the Actor Model
BoldRadius Solutions
 
Akka framework
mitesh_sharma
 
Actors and Threads
mperham
 
Functional Programming and Concurrency Patterns in Scala
kellogh
 
Effective Scala: Programming Patterns
Vasil Remeniuk
 
Scala’s implicits
Pablo Francisco Pérez Hidalgo
 
Go Lang Tutorial
Wei-Ning Huang
 
Real-World Scala Design Patterns
NLJUG
 
Scala Implicits - Not to be feared
Derek Wyatt
 
Akka streams
mircodotta
 
Mongo db - How we use Go and MongoDB by Sam Helman
Hakka Labs
 
Ad

Similar to Akka in 100 slides or less (20)

PPTX
Reactive Programming using Actor Model in Akka
StephenKoc1
 
PPTX
The Actor Model - Towards Better Concurrency
Dror Bereznitsky
 
PDF
Actors: Not Just for Movies Anymore
VictorOps
 
PDF
Introduction to concurrent programming with akka actors
datamantra
 
PDF
Introduction to concurrent programming with Akka actors
Shashank L
 
ODP
Actors in the Small
Bill La Forge
 
PPTX
Oop2011 actor presentation_stal
Michael Stal
 
PDF
Actor, an elegant model for concurrent and distributed computation
Alessio Coltellacci
 
PPTX
Akka Actors
Dylan Forciea
 
PDF
Concurrent and Distributed Applications with Akka, Java and Scala
Fernando Rodriguez
 
PPTX
Creating scalable message driven solutions akkadotnet
David Hoerster
 
PDF
Akka (BeJUG)
Sander Mak (@Sander_Mak)
 
ODP
GPars (Groovy Parallel Systems)
Gagan Agrawal
 
PPTX
Introduction to actor model with examples on Akka.NET
Arthur Shvetsov
 
PDF
Introducing Akka
Meetu Maltiar
 
PPTX
Introduction to Akka - Atlanta Java Users Group
Roy Russo
 
PPTX
Actor systems
Derek Morr
 
PDF
Introducingakkajavazone2012 120914094033-phpapp02
Typesafe
 
KEY
Practical introduction to the actor model
Georgios Gousios
 
PDF
Akka scalaliftoff london_2010
Skills Matter
 
Reactive Programming using Actor Model in Akka
StephenKoc1
 
The Actor Model - Towards Better Concurrency
Dror Bereznitsky
 
Actors: Not Just for Movies Anymore
VictorOps
 
Introduction to concurrent programming with akka actors
datamantra
 
Introduction to concurrent programming with Akka actors
Shashank L
 
Actors in the Small
Bill La Forge
 
Oop2011 actor presentation_stal
Michael Stal
 
Actor, an elegant model for concurrent and distributed computation
Alessio Coltellacci
 
Akka Actors
Dylan Forciea
 
Concurrent and Distributed Applications with Akka, Java and Scala
Fernando Rodriguez
 
Creating scalable message driven solutions akkadotnet
David Hoerster
 
Akka (BeJUG)
Sander Mak (@Sander_Mak)
 
GPars (Groovy Parallel Systems)
Gagan Agrawal
 
Introduction to actor model with examples on Akka.NET
Arthur Shvetsov
 
Introducing Akka
Meetu Maltiar
 
Introduction to Akka - Atlanta Java Users Group
Roy Russo
 
Actor systems
Derek Morr
 
Introducingakkajavazone2012 120914094033-phpapp02
Typesafe
 
Practical introduction to the actor model
Georgios Gousios
 
Akka scalaliftoff london_2010
Skills Matter
 
Ad

Recently uploaded (20)

PDF
Why TechBuilder is the Future of Pickup and Delivery App Development (1).pdf
TechBuilder
 
PPTX
Oracle E-Business Suite: A Comprehensive Guide for Modern Enterprises
Conacent Consulting
 
PDF
How to Migrate SBCGlobal Email to Yahoo Easily
raymondjones7273
 
PPT
Introduction Database Management System for Course Database
ReinertYosua
 
PDF
System and Network Administraation Chapter 3
jaramharo
 
PPTX
Reimagine Home Health with the Power of Agentic AI​
AutomationEdge Technologies
 
PPTX
Lecture 3: Operating Systems Introduction to Computer Hardware Systems
hci7se
 
PDF
Designing Intelligence for the Shop Floor.pdf
nikglvk
 
PDF
Design an Analysis of Algorithms I-SECS-1021-03
DilanEscobar1
 
PDF
Internet Downloader Manager (IDM) Crack 6.42 Build 42 Updates Latest 2025
itskinga12
 
PPTX
L1 - Introduction to python Backend.pptx
MoizAhmed480282
 
PPTX
history of c programming in notes for students .pptx
Vijayakumari829030
 
PDF
2025 Textile ERP Trends: SAP, Odoo & Oracle
Aetos Technologies
 
PDF
Digital Systems & Binary Numbers (comprehensive )
fyfhqfhtv2
 
PDF
Digital Strategies for Manufacturing Companies
Virendra Rai, PMP
 
PDF
Softaken Excel to vCard Converter Software.pdf
markwillsonmw004
 
PDF
Internet Downloader Manager (IDM) Crack 6.42 Build 41
ghrom2211g
 
PDF
Wondershare Filmora 15 Crack With Activation Key [2025
ghrom2211g
 
PDF
Understanding Forklifts - TECH EHS Solution
TECH EHS Solution
 
PDF
wealthsignaloriginal-com-DS-text-... (1).pdf
skmiani786
 
Why TechBuilder is the Future of Pickup and Delivery App Development (1).pdf
TechBuilder
 
Oracle E-Business Suite: A Comprehensive Guide for Modern Enterprises
Conacent Consulting
 
How to Migrate SBCGlobal Email to Yahoo Easily
raymondjones7273
 
Introduction Database Management System for Course Database
ReinertYosua
 
System and Network Administraation Chapter 3
jaramharo
 
Reimagine Home Health with the Power of Agentic AI​
AutomationEdge Technologies
 
Lecture 3: Operating Systems Introduction to Computer Hardware Systems
hci7se
 
Designing Intelligence for the Shop Floor.pdf
nikglvk
 
Design an Analysis of Algorithms I-SECS-1021-03
DilanEscobar1
 
Internet Downloader Manager (IDM) Crack 6.42 Build 42 Updates Latest 2025
itskinga12
 
L1 - Introduction to python Backend.pptx
MoizAhmed480282
 
history of c programming in notes for students .pptx
Vijayakumari829030
 
2025 Textile ERP Trends: SAP, Odoo & Oracle
Aetos Technologies
 
Digital Systems & Binary Numbers (comprehensive )
fyfhqfhtv2
 
Digital Strategies for Manufacturing Companies
Virendra Rai, PMP
 
Softaken Excel to vCard Converter Software.pdf
markwillsonmw004
 
Internet Downloader Manager (IDM) Crack 6.42 Build 41
ghrom2211g
 
Wondershare Filmora 15 Crack With Activation Key [2025
ghrom2211g
 
Understanding Forklifts - TECH EHS Solution
TECH EHS Solution
 
wealthsignaloriginal-com-DS-text-... (1).pdf
skmiani786
 

Akka in 100 slides or less

  • 1. Akka in 100 slides or less Derek Wyatt Twitter: @derekwyatt Email: derek@derekwyatt.orgAugust 2015
  • 3. Akka is Concurrency Actors: Living objects with concurrent context “I am for you, Alrik of Valt.”
  • 4. Akka is Concurrency Actors: Living objects with concurrent context Futures: These aren’t Java’s Futures val  futureData  =  for  {      response  <-­‐  httpGet(…)      query  =  response.body.as[Query]      (img,  text)  <-­‐  imageQuery(query)      scaledImg  <-­‐  scaleImg(img)   }  yield  NewPostData(text,  scaledImg) “I am for you, Alrik of Valt.”
  • 5. Akka is Concurrency Actors: Living objects with concurrent context Futures: These aren’t Java’s Futures val  futureData  =  for  {      response  <-­‐  httpGet(…)      query  =  response.body.as[Query]      (img,  text)  <-­‐  imageQuery(query)      scaledImg  <-­‐  scaleImg(img)   }  yield  NewPostData(text,  scaledImg) Asynchronous Asynchronous Asynchronous Asynchronous “I am for you, Alrik of Valt.”
  • 6. Akka is Concurrency Actors: Living objects with concurrent context Futures: These aren’t Java’s Futures val  futureData  =  for  {      response  <-­‐  httpGet(…)      query  =  response.body.as[Query]      (img,  text)  <-­‐  imageQuery(query)      scaledImg  <-­‐  scaleImg(img)   }  yield  NewPostData(text,  scaledImg) Asynchronous Asynchronous Asynchronous Asynchronous Streams: Async Non-Blocking and Back-Pressured Source Sink Demand Supply Http too… “I am for you, Alrik of Valt.”
  • 7. Akka is Concurrency Actors: Living objects with concurrent context Futures: These aren’t Java’s Futures val  futureData  =  for  {      response  <-­‐  httpGet(…)      query  =  response.body.as[Query]      (img,  text)  <-­‐  imageQuery(query)      scaledImg  <-­‐  scaleImg(img)   }  yield  NewPostData(text,  scaledImg) Asynchronous Asynchronous Asynchronous Asynchronous Streams: Async Non-Blocking and Back-Pressured Source Sink Demand Supply Http too… “I am for you, Alrik of Valt.” Support for Scala and Java (but use Scala, cuz…)
  • 9. Actors: Concurrency in Isolation count: _ alert: _ score: _
  • 10. Actors: Concurrency in Isolation count: 2 alert: Y score: 16 count: 4 alert: N score: 2 count: 33 alert: G score: 71 count: 13 alert: G score: 12 count: 7 alert: X score: 5 count: 8 alert: N score: 11 count: 2 alert: I score: 14 count: 87 alert: G score: 0 count: 1 alert: B score: 6 count: 7 alert: W score: 32 count: 7 alert: O score: 19 count: 4 alert: G score: 99 count: _ alert: _ score: _ ✗Construct as many as you’d like
  • 11. Actors: Concurrency in Isolation count: 2 alert: Y score: 16 count: 4 alert: N score: 2 count: 33 alert: G score: 71 count: 13 alert: G score: 12 count: 7 alert: X score: 5 count: 8 alert: N score: 11 count: 2 alert: I score: 14 count: 87 alert: G score: 0 count: 1 alert: B score: 6 count: 7 alert: W score: 32 count: 7 alert: O score: 19 count: 4 alert: G score: 99 count: _ alert: _ score: _ ✗Construct as many as you’d like ✗Each one encapsulates its own state
  • 12. Actors: Concurrency in Isolation count: 2 alert: Y score: 16 count: 4 alert: N score: 2 count: 33 alert: G score: 71 count: 13 alert: G score: 12 count: 7 alert: X score: 5 count: 8 alert: N score: 11 count: 2 alert: I score: 14 count: 87 alert: G score: 0 count: 1 alert: B score: 6 count: 7 alert: W score: 32 count: 7 alert: O score: 19 count: 4 alert: G score: 99 Thread Thread count: _ alert: _ score: _ ✗Construct as many as you’d like ✗Each one encapsulates its own state ✗They all (can) share the same thread pool
  • 13. Actors: Concurrency in Isolation count: 2 alert: Y score: 16 count: 4 alert: N score: 2 count: 33 alert: G score: 71 count: 13 alert: G score: 12 count: 7 alert: X score: 5 count: 8 alert: N score: 11 count: 2 alert: I score: 14 count: 87 alert: G score: 0 count: 1 alert: B score: 6 count: 7 alert: W score: 32 count: 7 alert: O score: 19 count: 4 alert: G score: 99 Thread Thread count: _ alert: _ score: _ ✗Construct as many as you’d like ✗Each one encapsulates its own state ✗They all (can) share the same thread pool ✗They cannot interfere with each other
  • 14. Actors: Concurrency in Isolation count: 2 alert: Y score: 16 count: 4 alert: N score: 2 count: 33 alert: G score: 71 count: 8 alert: N score: 11 count: 2 alert: I score: 14 count: 87 alert: G score: 0 count: 1 alert: B score: 6 count: 7 alert: W score: 32 count: 7 alert: O score: 19 count: 4 alert: G score: 99 Thread Thread count: _ alert: _ score: _ ✗Construct as many as you’d like ✗Each one encapsulates its own state ✗They all (can) share the same thread pool ✗They cannot interfere with each other ✗Their life-cycles are entirely under your control
  • 15. It’s all about the messages!
  • 16. It’s all about the messages! Actors have no public methods⦿ A
  • 17. It’s all about the messages! Actors have no public methods⦿ Actors have no publicly accessible data⦿ A B
  • 18. It’s all about the messages! Actors have no public methods⦿ Actors have no publicly accessible data⦿ You cannot communicate with Actors Synchronously ⦿ A B
  • 19. It’s all about the messages! Actors have no public methods⦿ Actors have no publicly accessible data⦿ You cannot communicate with Actors Synchronously ⦿ The only way to talk to them is with Messages ⦿ A B hey
  • 20. It’s all about the messages! Actors have no public methods⦿ Actors have no publicly accessible data⦿ You cannot communicate with Actors Synchronously ⦿ The only way to talk to them is with Messages ⦿ The only way to access their data is with Messages ⦿ A B 83
  • 21. It’s all about the messages! Actors have no public methods⦿ Actors have no publicly accessible data⦿ You cannot communicate with Actors Synchronously ⦿ The only way to talk to them is with Messages ⦿ The only way to access their data is with Messages ⦿ Messages can (and should) carry conversational state ⦿ A B A
  • 22. It’s all about the messages! Actors have no public methods⦿ Actors have no publicly accessible data⦿ You cannot communicate with Actors Synchronously ⦿ The only way to talk to them is with Messages ⦿ The only way to access their data is with Messages ⦿ Messages can (and should) carry conversational state ⦿ A B A Done(a,b,c)
  • 23. Actors are Fault Tolerant Parent Child Child Child Mailbox Mailbox Mailbox Mailbox
  • 24. Actors are Fault Tolerant Actors supervise their children Parent Child Child Child Mailbox Mailbox Mailbox Mailbox
  • 25. Actors are Fault Tolerant Actors supervise their children Failed Actors are restarted (or stopped, or resumed, or escalated) by their supervisors Parent Child Child Child Mailbox Mailbox Mailbox Mailbox
  • 26. Actors are Fault Tolerant Actors supervise their children Failed Actors are restarted (or stopped, or resumed, or escalated) by their supervisors Restarted Actors are given a fresh state Parent Child Child Child Mailbox Mailbox Mailbox Mailbox
  • 27. Actors are Fault Tolerant Actors supervise their children Failed Actors are restarted (or stopped, or resumed, or escalated) by their supervisors Restarted Actors are given a fresh state The message they were processing is lost Parent Child Child Child Mailbox Mailbox Mailbox Mailbox
  • 28. Actors are Fault Tolerant Actors supervise their children Failed Actors are restarted (or stopped, or resumed, or escalated) by their supervisors Restarted Actors are given a fresh state The message they were processing is lost Parent Child Child Mailbox Mailbox Mailbox Mailbox Child
  • 29. Death is Actionable Parent Child ChildChild Deathwatch Mailbox
  • 30. Death is Actionable ❉ Restarting is invisible to outsiders… ❉ …But Actor Death is visible ❉ Deathwatch lets Actors react to death, such as to recreate a child Parent Child ChildChild Deathwatch Mailbox
  • 31. Death is Actionable ❉ Restarting is invisible to outsiders… ❉ …But Actor Death is visible ❉ Deathwatch lets Actors react to death, such as to recreate a child Parent ChildChildChild Deathwatch Mailbox
  • 32. Death is Actionable ❉ Restarting is invisible to outsiders… ❉ …But Actor Death is visible ❉ Deathwatch lets Actors react to death, such as to recreate a child Parent ChildChildChild Deathwatch Mailbox ❉ … Or a transaction is complete, or it’s time to shut down, or a current stage of processing is finished, or…
  • 33. Death is Actionable ❉ Restarting is invisible to outsiders… ❉ …But Actor Death is visible ❉ Deathwatch lets Actors react to death, such as to recreate a child Parent ChildChildChild Deathwatch Mailbox ❉ Remember that this is death, so the mailbox contents are lost ❉ … Or a transaction is complete, or it’s time to shut down, or a current stage of processing is finished, or…
  • 34. So, why would I use Actors?
  • 35. So, why would I use Actors? ✗Actors help you manage concurrency Reasoning
  • 36. So, why would I use Actors? ✗Actors help you manage concurrency ✗Actors let you implement services within your system Reasoning Service decoupling
  • 37. So, why would I use Actors? ✗Actors help you manage concurrency ✗Actors let you implement services within your system ✗Actors let you design an entirely asynchronous system Reasoning Service decoupling Capacity and Throughput
  • 38. So, why would I use Actors? ✗Actors help you manage concurrency ✗Actors let you implement services within your system ✗Actors let you design an entirely asynchronous system ✗Actors let you define the resiliency of your applications Reasoning Service decoupling Capacity and Throughput Fault Tolerance
  • 39. So, why would I use Actors? ✗Actors help you manage concurrency ✗Actors let you implement services within your system ✗Actors let you design an entirely asynchronous system ✗Actors let you define the resiliency of your applications ✗ Eventual consistency, and message delivery failure are realities that Actors help you deal with throughout your code Reasoning Service decoupling Capacity and Throughput Fault Tolerance Massive Scale Self Healing
  • 40. So, why would I use Actors? ✗Actors help you manage concurrency ✗Actors let you implement services within your system ✗Actors let you design an entirely asynchronous system ✗Actors let you define the resiliency of your applications ✗ Eventual consistency, and message delivery failure are realities that Actors help you deal with throughout your code ✗ Most importantly, Actors help you think about the problem differently and express your solutions more creatively Reasoning Service decoupling Capacity and Throughput Fault Tolerance Massive Scale Self Healing Sanity, Clarity, and Reasonability!!
  • 42. “Functional” Futures ◎ A Future is just a value, but not yet…
  • 43. “Functional” Futures ◎ A Future is just a value, but not yet… ◎ java.util.concurrent.Future is a bad Future. Akka gave us Futures that compose!
  • 44. “Functional” Futures ◎ A Future is just a value, but not yet… ◎ java.util.concurrent.Future is a bad Future. Akka gave us Futures that compose! ◎ Composable Futures let us abstract over Future values, rather than wait for them for {
  • 45. “Functional” Futures ◎ A Future is just a value, but not yet… ◎ java.util.concurrent.Future is a bad Future. Akka gave us Futures that compose! ◎ Composable Futures let us abstract over Future values, rather than wait for them for { a <- futureA() futureA()
  • 46. futureB(a) “Functional” Futures ◎ A Future is just a value, but not yet… ◎ java.util.concurrent.Future is a bad Future. Akka gave us Futures that compose! ◎ Composable Futures let us abstract over Future values, rather than wait for them for { a <- futureA() b <- futureB(a) futureA()
  • 47. futureC(a,b) futureB(a) “Functional” Futures ◎ A Future is just a value, but not yet… ◎ java.util.concurrent.Future is a bad Future. Akka gave us Futures that compose! ◎ Composable Futures let us abstract over Future values, rather than wait for them for { a <- futureA() b <- futureB(a) c <- futureC(a,b) futureA()
  • 48. futureC(a,b) futureB(a) “Functional” Futures ◎ A Future is just a value, but not yet… ◎ java.util.concurrent.Future is a bad Future. Akka gave us Futures that compose! ◎ Composable Futures let us abstract over Future values, rather than wait for them for { a <- futureA() b <- futureB(a) c <- futureC(a,b) } yield c futureA() One composed Future
  • 49. futureC(a,b) futureB(a) “Functional” Futures ◎ A Future is just a value, but not yet… ◎ java.util.concurrent.Future is a bad Future. Akka gave us Futures that compose! ◎ Composable Futures let us abstract over Future values, rather than wait for them for { a <- futureA() b <- futureB(a) c <- futureC(a,b) } yield c futureA() ◎ Futures compose as Monads compose, which makes them “standard” functional abstractions, and that’s a powerful thing One composed Future
  • 51. Abolish Callback Hell public void restHandler(RESTRequest req) { idservice.validate(req.userInfo, new Callback<ValidateResult>() { public void run(ValidateResult result) { if (result.isValid) { db.getProfile(req.userId, new Callback<UserProfile>() { public void run(UserProfile profile) { picServer.get(profile.pic1, new Callback<Pic>() { public void run(Pic p1) { picServer.get(profile.pic2, new Callback<Pic>() { public void run(Pic p2) { picServer.get(profile.pic3, new Callback<Pic>() { public void run(Pic p3) { picServer.get(profile.pic4, new Callback<Pic>() { public void run(Pic p4) { picServer.get(profile.pic5, new Callback<Pic>() { public void run(Pic p5) { twitterServer.getRecentActivity(req.userInfo, new Callback<TwitterActivity>() { public void run(TwitterActivity activity) { req.sendResponse(pic1, pic2, pic3, pic4, pic5, activity) } } } } } } } }
  • 52. Abolish Callback Hell public void restHandler(RESTRequest req) { idservice.validate(req.userInfo, new Callback<ValidateResult>() { public void run(ValidateResult result) { if (result.isValid) { db.getProfile(req.userId, new Callback<UserProfile>() { public void run(UserProfile profile) { picServer.get(profile.pic1, new Callback<Pic>() { public void run(Pic p1) { picServer.get(profile.pic2, new Callback<Pic>() { public void run(Pic p2) { picServer.get(profile.pic3, new Callback<Pic>() { public void run(Pic p3) { picServer.get(profile.pic4, new Callback<Pic>() { public void run(Pic p4) { picServer.get(profile.pic5, new Callback<Pic>() { public void run(Pic p5) { twitterServer.getRecentActivity(req.userInfo, new Callback<TwitterActivity>() { public void run(TwitterActivity activity) { req.sendResponse(pic1, pic2, pic3, pic4, pic5, activity) } } } } } } } } We didn’t handle errors We didn’t handle timeouts It’s not necessarily Threadsafe It’s incredibly hard to read
  • 53. Compose your Futures implicit val _timeout = Timeout(30.seconds) def restHandler(req: RESTRequest): Future[RESTResponse] = { val resp = for { validity <- idService.validate(req.userInfo) if validity.isValid profile <- db.getProfile(req.userId) pic1 <- picServer.get(profile.pic1) pic2 <- picServer.get(profile.pic2) pic3 <- picServer.get(profile.pic3) pic4 <- picServer.get(profile.pic4) pic5 <- picServer.get(profile.pic5) activity <- twitterServer.getRecentActivity(req.userInfo) } yield SuccessfulResponse(pic1, pic2, pic3, pic4, pic5, activity) resp recover { e: Throwable => FailedResponse(e) } }
  • 54. Compose your Futures implicit val _timeout = Timeout(30.seconds) def restHandler(req: RESTRequest): Future[RESTResponse] = { val resp = for { validity <- idService.validate(req.userInfo) if validity.isValid profile <- db.getProfile(req.userId) pic1 <- picServer.get(profile.pic1) pic2 <- picServer.get(profile.pic2) pic3 <- picServer.get(profile.pic3) pic4 <- picServer.get(profile.pic4) pic5 <- picServer.get(profile.pic5) activity <- twitterServer.getRecentActivity(req.userInfo) } yield SuccessfulResponse(pic1, pic2, pic3, pic4, pic5, activity) resp recover { e: Throwable => FailedResponse(e) } } Errors have been handled Timeouts have been handled It’s (probably) Threadsafe I didn’t have to shrink the font
  • 55. So why would I use Futures?
  • 56. So why would I use Futures? Asynchronous programming is still hard⦿
  • 57. So why would I use Futures? Asynchronous programming is still hard⦿ Programming synchronously isn’t a reasonable response⦿ Thread starvation timeouts capacity issues thread thrashing
  • 58. So why would I use Futures? Asynchronous programming is still hard⦿ Programming synchronously isn’t a reasonable response⦿ Scala Futures embody asynchronous values⦿ Thread starvation timeouts capacity issues thread thrashing Everything is a value
  • 59. So why would I use Futures? Asynchronous programming is still hard⦿ Programming synchronously isn’t a reasonable response⦿ Scala Futures embody asynchronous values⦿ They let us express composed asynchronous computation⦿ Thread starvation timeouts capacity issues thread thrashing Everything is a value Less Side Effects
  • 60. So why would I use Futures? Asynchronous programming is still hard⦿ Programming synchronously isn’t a reasonable response⦿ Scala Futures embody asynchronous values⦿ They let us express composed asynchronous computation⦿ Futures let us propagate errors and recover from them⦿ Thread starvation timeouts capacity issues thread thrashing Everything is a value Less Side Effects Graceful Failure Resiliency
  • 61. So why would I use Futures? Asynchronous programming is still hard⦿ Programming synchronously isn’t a reasonable response⦿ Scala Futures embody asynchronous values⦿ They let us express composed asynchronous computation⦿ Futures let us propagate errors and recover from them⦿ Asynchronous programming has always been possible but Futures now make it much more viable ⦿ Thread starvation timeouts capacity issues thread thrashing Everything is a value Less Side Effects Graceful Failure Resiliency
  • 62. Operating on Data Streams
  • 63. Operating on Data Streams ❉ In the real world, we communicate with things Networks Disks Databases Services Slower Algorithms
  • 64. Operating on Data Streams ❉ In the real world, we communicate with things Networks Disks Databases Services Slower Algorithms ❉ Polling sucks. We live in a real time world.
  • 65. Operating on Data Streams ❉ In the real world, we communicate with things Networks Disks Databases Services Slower Algorithms ❉ Polling sucks. We live in a real time world. ❉ Eventing can be hard, since it doesn’t compose
  • 66. Operating on Data Streams ❉ In the real world, we communicate with things Networks Disks Databases Services Slower Algorithms ❉ Polling sucks. We live in a real time world. ❉ Eventing can be hard, since it doesn’t compose ❉ Throttling is a real problem we never address
  • 67. Operating on Data Streams ❉ In the real world, we communicate with things Networks Disks Databases Services Slower Algorithms ❉ Polling sucks. We live in a real time world. ❉ Eventing can be hard, since it doesn’t compose ❉ Throttling is a real problem we never address ❉ Akka Streams help us solve all of these problems
  • 68. Operating on Data Streams ❉ In the real world, we communicate with things Networks Disks Databases Services Slower Algorithms ❉ Polling sucks. We live in a real time world. ❉ Eventing can be hard, since it doesn’t compose ❉ Throttling is a real problem we never address ❉ Akka Streams help us solve all of these problems Source Transformation Flow Transformation Flow Sink Demand Supply
  • 69. BackPressure is key Source Sink
  • 70. BackPressure is key ◎ Fast producers can kill; we only have so much RAM Source Sink
  • 71. BackPressure is key ◎ Fast producers can kill; we only have so much RAM ◎ Producers can’t be artificially slow just to be nice Source Sink
  • 72. BackPressure is key ◎ Fast producers can kill; we only have so much RAM ◎ Producers can’t be artificially slow just to be nice ◎ Consumers signal demand, Producers signal supply Source Sink
  • 73. BackPressure is key ◎ Fast producers can kill; we only have so much RAM ◎ Producers can’t be artificially slow just to be nice ◎ Consumers signal demand, Producers signal supply ◎ When a consumer is slow, it signals no demand Source Sink
  • 74. BackPressure is key ◎ Fast producers can kill; we only have so much RAM ◎ Producers can’t be artificially slow just to be nice ◎ Consumers signal demand, Producers signal supply ◎ When a consumer is slow, it signals no demand ◎ When a producer is slow, it doesn’t supply Source Sink
  • 75. BackPressure is key ◎ Fast producers can kill; we only have so much RAM ◎ Producers can’t be artificially slow just to be nice ◎ Consumers signal demand, Producers signal supply ◎ When a consumer is slow, it signals no demand ◎ When a producer is slow, it doesn’t supply Source Sink Supply
  • 77. Composable Binary Protocols Framer ByteString ByteString BidiFlow Serializer Object ByteString BidiFlow Chunker ByteString ByteString BidiFlow
  • 78. Composable Binary Protocols Framer ByteString ByteString BidiFlow Serializer Object ByteString BidiFlow Chunker ByteString ByteString BidiFlow Application Object Object Source Sink Network ByteString ByteString Source Sink BidiFlow ByteStringObject
  • 79. Composable Binary Protocols Framer ByteString ByteString BidiFlow Serializer Object ByteString BidiFlow Chunker ByteString ByteString BidiFlow Application Object Object Source Sink Network ByteString ByteString Source Sink BidiFlow ByteStringObject ✗Entirely reusable components that fit in any BiDirectional Flow
  • 80. Composable Binary Protocols Framer ByteString ByteString BidiFlow Serializer Object ByteString BidiFlow Chunker ByteString ByteString BidiFlow Application Object Object Source Sink Network ByteString ByteString Source Sink BidiFlow ByteStringObject ✗Entirely reusable components that fit in any BiDirectional Flow ✗Type safe (or as type safe as byte string marshaling gets)
  • 81. Composable Binary Protocols Framer ByteString ByteString BidiFlow Serializer Object ByteString BidiFlow Chunker ByteString ByteString BidiFlow Application Object Object Source Sink Network ByteString ByteString Source Sink BidiFlow ByteStringObject ✗Entirely reusable components that fit in any BiDirectional Flow ✗Type safe (or as type safe as byte string marshaling gets) ✗Entirely back pressured from end to end
  • 82. Composable Binary Protocols Framer ByteString ByteString BidiFlow Serializer Object ByteString BidiFlow Chunker ByteString ByteString BidiFlow Application Object Object Source Sink Network ByteString ByteString Source Sink BidiFlow ByteStringObject ✗Entirely reusable components that fit in any BiDirectional Flow ✗Type safe (or as type safe as byte string marshaling gets) ✗Entirely back pressured from end to end ✗100% event driven and reactive Realtime Speeds No Blocking Threads Natural Throttling graceful performance degradationNot a Crash
  • 83. Why Would I use Streams?
  • 84. Why Would I use Streams? Streaming is (probably) the crown jewel of Akka’s offering (but it’s a tough call)
  • 85. Why Would I use Streams? Streaming is (probably) the crown jewel of Akka’s offering The need to respond to backpressure is real and we never do it ! (but it’s a tough call)
  • 86. Why Would I use Streams? Streaming is (probably) the crown jewel of Akka’s offering The need to respond to backpressure is real and we never do it The need to treat our threads with respect is important ! ! (but it’s a tough call)
  • 87. Why Would I use Streams? Streaming is (probably) the crown jewel of Akka’s offering The need to respond to backpressure is real and we never do it The need to treat our threads with respect is important The need to be reactive and fast is vital to the user experience ! ! ! (but it’s a tough call)
  • 88. Why Would I use Streams? Streaming is (probably) the crown jewel of Akka’s offering The need to respond to backpressure is real and we never do it The need to treat our threads with respect is important The need to be reactive and fast is vital to the user experience Streams give us all of this and let us use our hardware to its fullest ! ! ! !!! (but it’s a tough call)
  • 89. Akka from 20k feetAkka from 20k feet
  • 90. Akka from 20k feetAkka from 20k feet Actors! Actors! Live Objects Supervised Asynchronous Message Passing Services State Machines Network Ready
  • 91. Akka from 20k feetAkka from 20k feet Actors! Actors! Futures! Futures! Live Objects Supervised Asynchronous Message Passing Services State Machines Network Ready Composable Values Reactive Monadic Immutable Threadsafe Work Well with Actors
  • 92. Akka from 20k feetAkka from 20k feet Actors! Actors! Futures! Futures! Streams! Streams! Live Objects Supervised Asynchronous Message Passing Services State Machines Network Ready Composable Values Reactive Monadic Immutable Threadsafe Work Well with Actors BackPressured Composable Reusable Event Driven Flexible Lots of Activity and Support Work with Futures and Actors
  • 93. Go Get AKKA!Go Get AKKA! Website: http://akka.io Scala Reference: http://doc.akka.io/docs/akka/current/scala.html Java Reference: http://doc.akka.io/docs/akka/current/java.html Streams Reference: http://doc.akka.io/docs/akka-stream-and-http-experimental/current/scala.html Derek Wyatt Twitter: @derekwyatt Email: derek@derekwyatt.orgAugust 2015