Akka in 100 slides or less

Akkain 100 slides or less

Derek Wyatt Twitter: @derekwyatt

Email: [email protected] 2015

mailto:[email protected]

Akka is Concurrency

Akka is Concurrency

Actors: Living objects with concurrent context

“I am for you, Alrik of Valt.”

Akka is Concurrency


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)


Akka is Concurrency




Asynchronous

Asynchronous

Asynchronous

Asynchronous


Akka is Concurrency




Asynchronous

Asynchronous

Asynchronous

Asynchronous

Streams: Async Non-Blocking and Back-PressuredSource

Sink

Demand

Supply

Http too…


Akka is Concurrency




Asynchronous

Asynchronous

Asynchronous

Asynchronous

Streams: Async Non-Blocking and Back-PressuredSource

Sink

Demand

Supply

Http too…


Support for Scala and Java (but use Scala, cuz…)

Actors: Concurrency in Isolation

Actors: Concurrency in Isolation

count: _alert: _score: _

Actors: Concurrency in Isolationcount: 2alert: Yscore: 16

count: 4alert: Nscore: 2

count: 33alert: Gscore: 71


count: 7alert: Xscore: 5


count: 2alert: Iscore: 14


count: 1alert: Bscore: 6

count: 7alert: Wscore: 32

count: 7alert: Oscore: 19



✗Construct as many as you’d like















✗Each one encapsulates its own state













Thre

ad

Thre

ad




✗They all (can) share the same thread pool













Thre

ad

Thre

ad





✗They cannot interfere with each other











Thre

ad

Thre

ad





✗They cannot interfere with each other

✗Their life-cycles are entirely under your control

It’s all about the messages!


Actors have no public methods⦿ A


Actors have no public methods⦿

Actors have no publicly accessible data⦿

A B




You cannot communicate with Actors Synchronously⦿

A B





The only way to talk to them is with Messages⦿

A Bhey






The only way to access their data is with Messages⦿

A B83







Messages can (and should) carry conversational state⦿

A B

A







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 supervise their childrenParent

Child Child Child

Mailbox

Mailbox

Mailbox Mailbox


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




Restarted Actors are given a fresh state

Parent

Child Child Child

Mailbox

Mailbox

Mailbox Mailbox





The message they were processing is lost

Parent

Child Child Child

Mailbox

Mailbox

Mailbox Mailbox





The message they were processing is lost

Parent

Child Child

Mailbox

Mailbox

Mailbox Mailbox

Child

Death is ActionableParent

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




Parent

ChildChildChild

Deathwatch

Mailbox




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…




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



✗Actors let you design an entirely asynchronous system

Reasoning

Service decoupling

Capacity and Throughput




✗Actors let you define the resiliency of your applications

Reasoning

Service decoupling


Fault Tolerance





✗Eventual consistency, and message delivery failure are realities that Actors help you deal with throughout your code

Reasoning

Service decoupling


Fault Tolerance

Massive Scale

Self Healing





✗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


Fault Tolerance

Massive Scale

Self Healing

Sanity, Clarity, and Reasonability!!

“Functional” Futures

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




for { a <- futureA()

futureA()

futureB(a)




for { a <- futureA() b <- futureB(a)

futureA()

futureC(a,b) futureB(a)




for { a <- futureA() b <- futureB(a) c <- futureC(a,b)

futureA()





for { a <- futureA() b <- futureB(a) c <- futureC(a,b)} yield c

futureA()One

compo

sed

Future





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 c

ompose

d

Future

Abolish Callback Hell

Abolish Callback Hellpublic 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 Hellpublic 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 Futuresimplicit 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 Futuresimplicit 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?


Asynchronous programming is still hard⦿



Programming synchronously isn’t a reasonable response⦿Thread starvation

timeoutscapacity is

suesthread thrashing



Programming synchronously isn’t a reasonable response⦿

Scala Futures embody asynchronous values⦿

Thread starvation

timeoutscapacity is


Everything is a value





They let us express composed asynchronous computation⦿

Thread starvation

timeoutscapacity is



Less Side Effects






Futures let us propagate errors and recover from them⦿

Thread starvation

timeoutscapacity is



Less Side Effects

Graceful Failure

Resiliency






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

timeoutscapacity is



Less Side Effects

Graceful Failure

Resiliency

Operating on Data Streams

Operating on Data Streams❉ In the real world, we communicate with things

NetworksDisks

Databases Services Slower Algorithms


NetworksDisks

Databases Services Slower Algorithms❉ Polling sucks. We live in a real time world.


NetworksDisks


❉ Eventing can be hard, since it doesn’t compose


NetworksDisks



❉ Throttling is a real problem we never address


NetworksDisks




❉ Akka Streams help us solve all of these problems


NetworksDisks




❉ Akka Streams help us solve all of these problems

Source

Transformation Flow

Transformation Flow

Sink

Demand

Supply

BackPressure is keySource

Sink

BackPressure is key◎ Fast producers can kill; we only have so much RAM

Source

Sink


◎ Producers can’t be artificially slow just to be nice

Source

Sink



◎ Consumers signal demand, Producers signal supply

Source

Sink




◎ When a consumer is slow, it signals no demand

Source

Sink





◎ When a producer is slow, it doesn’t supply

Source

Sink





◎ When a producer is slow, it doesn’t supply

Source

Sink Supply

Composable Binary Protocols


FramerByteString ByteString

BidiFlow

SerializerObject ByteString

BidiFlow

ChunkerByteString ByteString

BidiFlow



BidiFlow


BidiFlow


BidiFlow

ApplicationObject Object

Source Sink

NetworkByteString ByteString

Source SinkBidiFlow

ByteStringObject



BidiFlow


BidiFlow


BidiFlow


Source Sink


Source SinkBidiFlow

ByteStringObject

✗Entirely reusable components that fit in any BiDirectional Flow



BidiFlow


BidiFlow


BidiFlow


Source Sink


Source SinkBidiFlow

ByteStringObject


✗Type safe (or as type safe as byte string marshaling gets)



BidiFlow


BidiFlow


BidiFlow


Source Sink


Source SinkBidiFlow

ByteStringObject



✗Entirely back pressured from end to end



BidiFlow


BidiFlow


BidiFlow


Source Sink


Source SinkBidiFlow

ByteStringObject



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


Streaming is (probably) the crown jewel of Akka’s offering (but it’s a tough call)


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)



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)





The need to be reactive and fast is vital to the user experience

!!!






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

!!!

! ! !


Akka from 20k feetAkka from 20k feet


Actors!Actors!Live Objects

Supervised

AsynchronousMessage Passing

ServicesState Machines

Network Ready


Actors!Actors!

Futures!Futures!

Live Objects

Supervised



Network Ready

Composable Values

ReactiveMonadic

Immutable

Threadsafe

Work Well with Actors


Actors!Actors!

Futures!Futures!

Streams!Streams!

Live Objects

Supervised



Network Ready

Composable Values

ReactiveMonadic

Immutable

Threadsafe

Work Well with Actors

BackPressured

Composable

Reusable

Event DrivenFlexible

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: [email protected] 2015

http://akka.io

http://doc.akka.io/docs/akka/current/scala.html

http://doc.akka.io/docs/akka/current/scala.html

http://doc.akka.io/docs/akka-stream-and-http-experimental/current/scala.html

mailto:[email protected]

Akka in 100 slides or less

Software