O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Akka in 100 slides or less

4.641 visualizações

Publicada em

I gave this presentation to my coworkers recently. Unfortunately, the animations done translate to PDF so it's a tad sucky, but the main content is there.

Publicada em: Software
  • DOWNLOAD FULL BOOKS, INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... ,DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ,DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ,DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ,DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ,DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ,DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui

Akka in 100 slides or less

  1. 1. Akka in 100 slides or less Derek Wyatt Twitter: @derekwyatt Email: derek@derekwyatt.orgAugust 2015
  2. 2. Akka is Concurrency
  3. 3. Akka is Concurrency Actors: Living objects with concurrent context “I am for you, Alrik of Valt.”
  4. 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. 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. 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. 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…)
  8. 8. Actors: Concurrency in Isolation
  9. 9. Actors: Concurrency in Isolation count: _ alert: _ score: _
  10. 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. 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. 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. 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. 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. 15. It’s all about the messages!
  16. 16. It’s all about the messages! Actors have no public methods⦿ A
  17. 17. It’s all about the messages! Actors have no public methods⦿ Actors have no publicly accessible data⦿ A B
  18. 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. 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. 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. 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. 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. 23. Actors are Fault Tolerant Parent Child Child Child Mailbox Mailbox Mailbox Mailbox
  24. 24. Actors are Fault Tolerant Actors supervise their children Parent Child Child Child Mailbox Mailbox Mailbox Mailbox
  25. 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. 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. 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. 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. 29. Death is Actionable Parent Child ChildChild Deathwatch Mailbox
  30. 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. 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. 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. 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. 34. So, why would I use Actors?
  35. 35. So, why would I use Actors? ✗Actors help you manage concurrency Reasoning
  36. 36. So, why would I use Actors? ✗Actors help you manage concurrency ✗Actors let you implement services within your system Reasoning Service decoupling
  37. 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. 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. 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. 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!!
  41. 41. “Functional” Futures
  42. 42. “Functional” Futures ◎ A Future is just a value, but not yet…
  43. 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. 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. 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. 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. 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. 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. 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
  50. 50. Abolish Callback Hell
  51. 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. 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. 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. 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. 55. So why would I use Futures?
  56. 56. So why would I use Futures? Asynchronous programming is still hard⦿
  57. 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. 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. 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. 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. 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. 62. Operating on Data Streams
  63. 63. Operating on Data Streams ❉ In the real world, we communicate with things Networks Disks Databases Services Slower Algorithms
  64. 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. 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. 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. 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. 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. 69. BackPressure is key Source Sink
  70. 70. BackPressure is key ◎ Fast producers can kill; we only have so much RAM Source Sink
  71. 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. 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. 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. 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. 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
  76. 76. Composable Binary Protocols
  77. 77. Composable Binary Protocols Framer ByteString ByteString BidiFlow Serializer Object ByteString BidiFlow Chunker ByteString ByteString BidiFlow
  78. 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. 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. 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. 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. 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. 83. Why Would I use Streams?
  84. 84. Why Would I use Streams? Streaming is (probably) the crown jewel of Akka’s offering (but it’s a tough call)
  85. 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. 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. 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. 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. 89. Akka from 20k feetAkka from 20k feet
  90. 90. Akka from 20k feetAkka from 20k feet Actors! Actors! Live Objects Supervised Asynchronous Message Passing Services State Machines Network Ready
  91. 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. 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. 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

×