Reactive applications with Akka.Net - DDD East Anglia 2015
Report
Share
•6 likes•2,925 views
Reactive applications with Akka.Net - DDD East Anglia 2015
•6 likes•2,925 views
Report
Share
Download to read offline
Application requirements have changed significantly over the past 20 years and we’re now building software which has to handle potentially millions of users and billions of devices. The reactive manifesto is a set of common traits shared by applications capable of handling these new requirements. Akka is the canonical example of a toolkit for building such applications, but thanks to a team of dedicated developers, Akka has arrived on the CLR in the form of Akka.Net. This session looks at the key principles of Akka.Net and how using these you can build applications which handle potentially massive traffic.
Recommended
More Related Content
What's hot
What's hot(20)
Viewers also liked
Viewers also liked(20)
Similar to Reactive applications with Akka.Net - DDD East Anglia 2015
Similar to Reactive applications with Akka.Net - DDD East Anglia 2015(20)
Recently uploaded
Recently uploaded(20)
![[2023] Putting the R! in R&D.pdf](https://cdn.slidesharecdn.com/ss_thumbnails/2023puttingtherinrd-231122234738-294b2909-thumbnail.jpg?width=768&fit=bounds)
Reactive applications with Akka.Net - DDD East Anglia 2015
- 1. Reactive Applications with akka.Net Anthony Brown @bruinbrown93 me@anthonyjbrown.co.uk
- 2. HI, I’m Anthony Software engineer at Adbrain me@anthonyjbrown.co.uk @bruinbrown93
- 3. Computers have changed… A lot
- 8. Some of the changes Faster processors More processor cores More RAM Faster networks with more bandwidth
- 9. We need to make sure applications are responsive to user actions
- 10. Moore’s Law
- 11. Scale up no longer possible
- 13. CPUs have more cores Networks are faster
- 14. Scale out is now possible
- 15. Scale out relies on doing lots of work simultaneously
- 16. To do work simultaneously, we need either parallelism or concurrency
- 17. Parallelism is easy for Embarrassingly parallel tasks
- 18. For more complex tasks, we need concurrency
- 19. Is there a difference?
- 20. Concurrency Parallelism Thread 1 Thread 2 Thread 1 Thread 2
- 23. CHECK OUT MY MULTITHREADED CODE
- 24. HOW MANY THREADS DOES IT TAKE TO CHANGE A LIGHTBULB?
- 25. We don’t want to write multithreaded code
- 27. You’ve probably used one Tasks
- 28. There’s another - actors
- 30. Why are tasks bad?
- 31. They’re not, they solve a different problem
- 32. Promote isolation over co- ordination
- 35. We said we need applications to be responsive
- 36. What does it mean for an application to be responsive?
- 37. For an application to be responsive, it needs to work no matter what the scenario
- 38. Heavy load
- 39. Service failure
- 40. If we want to manage these, we need loose coupling
- 41. Common language for these applications
- 44. Reactive applications React to their environment
- 46. using actors to write reactive applications
- 47. an actor is A mailbox behaviour state
- 48. We saw that actors are strongly isolated, they encapsulate their state
- 49. To modify the state, we have a behaviour which is responsible for it
- 50. We invoke the behaviour by sending it a message
- 51. Messages are processed serially but on separate threads
- 52. An actor can send a finite number of messages
- 53. An actor can spawn a finite number of actors
- 54. An actor can change how it responds to the next message
- 55. How can we write actors?
- 56. Using akka.Net
- 58. Step 1 Define an actor
- 59. class GreetingActor : ReceiveActor { public GreetingActor() { Receive<string>( s => Console.WriteLine(“Hello ” + s)); } }
- 60. Step 2 Create an actor system
- 61. var system = ActorSystem.Create(“GreeterSystem”);
- 62. Step 3 Spawn the actor
- 63. var greeterActor = system.ActorOf<GreeterActor>();
- 64. where is my actual actor? AKKA.net root actor your actors
- 65. Step 4 Talk to the actor
- 67. What about F#?
- 68. Full F# API
- 69. Built upon Erlang foundations
- 70. let Actor count = actor { let! msg = mailbox.Receive () printfn “Message %i: %A” count msg return! actor (count+1) }
- 72. Cloud brings about failure
- 73. your users don’t want to see THIS
- 74. Need to isolate failures quickly and automatically recover from them
- 75. How can we isolate errors?
- 77. Service aService B supervisor Request Response user error error action
- 78. Handling increased load in a distributed system
- 79. Easiest way to scale is to make the servers bigger
- 80. Scale up has a limit, scale out doesn't
- 81. Scale out is easy with isolation
- 82. Actors give us isolation therefore scalability is easy with actors
- 83. Routers
- 84. Taking akka.Net to the next level
- 85. Akka.Remote
- 86. Connecting 2 actor systems in a client-server architecture
- 87. Akka.Cluster
- 88. Takes remoting to the next level
- 89. Treat multiple machines as one actor system
- 91. Cluster sharding
- 92. Akka.Persistence
- 93. Allows for easy CQRS and Event sourcing with actors
- 95. Allows for sharing data between actors with strong eventual consistency
- 96. Where can I use akka.Net?
- 97. IoT applications
- 98. Job scheduling / cluster management
- 99. Gaming
- 100. User interfaces
- 102. akka.Net provides a solid foundation for the stronger constraints being imposed today and in the future
- 103. Want to learn more?
- 105. Reactive applications with akka.Net MEAP soon
- 107. Want to contribute?
- 108. Plenty of up for grabs issues github.com/akkadotnet/akka.net
- 110. Q & A