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.

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

12. What’s the options?

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

21. Concurrency is hard

22. MULTITHREADING
THEORY
PRACTICE

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

26. Use concurrency abstractions
instead

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

33. Actors are independent
entities

34. Why does this
matter?

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

42. Reactive
reactivemanifesto.org

43. RESPONSIVE
RESILIENT ELASTIC
MESSAGE PASSING

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

66. greeter.Tell(“DDDEA”);

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)
}

71. Resilience in
distributed
systems

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?

76. Separate error channels

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

90. Cluster aware routers

91. Cluster sharding

92. Akka.Persistence

93. Allows for easy CQRS and
Event sourcing with actors

94. Akka.DistributedData

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

101. Microservices deployments

102. akka.Net provides a solid foundation
for the stronger constraints being
imposed today and in the future

103. Want to learn
more?

104. akka.Net bootcamp
github.com/petabridge/akka-bootcamp

105. Reactive applications with
akka.Net MEAP soon

106. StackOverflow
stackoverflow.com/tags/akka.net

107. Want to
contribute?

108. Plenty of up for grabs issues
github.com/akkadotnet/akka.net

109. gitter.im/akkadotnet/akka.net

110. Q & A