The actor model is an old computer science concept, originating in 1973 and it laid dormant is largely a thought experiment for most of its history until the rise of the Internet. Now in the era of cheap, commodity cloud computing the actor model is staging a major comeback across all programming languages and runtimes, both for building distributed systems and for creating reactive mobile or desktop applications. In this talk, we will introduce the actor model through the use of Akka.NET, the most popular distributed actor model framework in .NET. We'll talk about what sorts of problems it solves well when you should use it, and what are some of the adoption costs and overhead involved in using a tool like Akka.NET. By the time you're finished with this talk, you should be familiar with most of the major Akka.NET and actor model concepts, basic Akka.NET syntax, and some ideas for how you might be able to use actors in your place of work. This talk is intended for developers, architects, and team leads.

1. When and How to Use the Actor
Model: an Introduction to
Akka.NET
Aaron Stannard, Co-Founder of
Akka.NET and Petabridge

2. Origins of the Actor Model

3. 1973 – Original Actor Model
Paper
Computer scientists thought
future computers would be
living-room sized
mainframes with thousands
of low-powered CPUs.
Thus, we needed a way to
write programs that could
run on multiple cores, a
novel concept at the time.
https://commons.wikimedia.org/w/index.php?curid=6455009

4. Actors in the 1970s
• Each actor is its own “micro process”
• Owns 1 core (there are thousands)
• Communicate across cores via message-
passing in shared memory
• Actors process 1 message at a time

5. Actors in the 1970s

6. Actors in the 1970s

7. 1970s Actors Never Came to
Pass

8. 1980s: Erlang Actors
• Development of network
computing revived actor
model.
• First implemented in 1986
by Ericsson. Powers
modern day GPRS, 3G,
and LTE cell networks.
• Used to provide fault
tolerance, soft-real time
programming, and linear
hardware scalability for
telephony networks.

9. Modern CPUs: More Cores!
Source: Karl Rupp https://www.karlrupp.net/2018/02/42-years-of-microprocessor-trend-data/

10. Modern Day: Actors Everywhere
• Multi-core programming now ubiquitous
• Developers need more robust model than
“shared state concurrent programming”
• Cloud computing == 1970s vision of
dividing work across thousands of cheap
CPUs finally comes true

11. Why Use the Actor Model?

12. Actors Reduce Big Problems
into Small Ones

13. • Accumulate state in-
memory.
• Can react to changes
in state in real-time.
• No database calls, I/O,
or external
infrastructure.
Actors are Reactive

14. Actors Make Concurrency Easy

15. Actors Isolate Faults

16. Actors Scale & Distribute

17. Actors Recover from Network
Failures

18. Actors Are Used in Domains
Where
• Soft real-time guarantees are common
– i.e. “every transaction must be completed
within ~100ms to be within SLA”
• Work is best modeled as streams
– Long-running jobs (i.e. Asset line
management, simulations, ETL, migrations)
– Continuous flows(i.e. IOT, marketing
automation, real-time pricing)
• High availability is key to business
success

19. Introduction to Akka.NET

20. PS> Install-Package Akka (base types)
PS> Install-Package Akka.Remote (networking)
PS> Install-Package Akka.Persistence (durable
actors)
PS> Install-Package Akka.Cluster (HA networking)
PS> Install-Package Akka.Streams (fun)
Installing Akka.NET

21. Basic Akka.NET Actor

22. Creating Actors

23. • Actor = a class that can contain state and modifies
that state by processing messages it receives.
• ActorReference = a handle to an actor. Allows you to
send the actor messages without knowing its
implementation type or location on network.
• ActorSystem = a collection of actors that exist inside
a single process and communicate via in-memory
message passing.
• Cluster = a collection of networked ActorSystems
whose actors communicate via TCP message
passing.
Actor Terms

24. Actors Always Run
Asynchronously

25. State is Shared Only Through
Messages

26. Actor References are
Location Transparent
• IActorRef can point to
local actor (in-
memory messaging.)
• IActorRef can point to
actor running in
another remote
process (TCP
messaging.)
• You don’t need to
explicitly know or care
which is which.

27. But Actors Still
Have Explicit Addresses

28. Processes Usually Contain
Many Actors

29. Using Actors in Practice

30. Business Case: Sdbkin
Fulfillment
• “The App Store meets NuGet”
• Fulfillment requires:
– Provisioning NuGet feed
– Processing payment + generating invoice
– Sending out email notifications to customer +
publisher
– Scheduling renewal
– Other stuff (taxes, payouts)

31. Model Orders as State
Machines
(Saga Pattern)

34. Actor Implementation
• OrderActor – uses Akka.Persistence
with EntityId == Stripe “IntentId” (or
equivalent)
• Internal state event sourced from
UserService / external payment system
events
• State isn’t persisted until user attempts to
pay
• Uses Akka.Persistence.Azure as backing
store

35. Actor Infrastructure
• Akka.Cluster – allows us to fault-tolerantly
place actors anywhere in our network
• Akka.Cluster.Sharding – guarantees that
each OrderActor will be globally unique;
moves actors around the cluster to load-balance
and recover from faults
• Akka.Persistence – makes it possible for
actors to recover their state after restart, failure,
or a deployment

37. • Event-driven applications (i.e. chat, workflow,
CRM)
• Finance (pricing, fraud detection, algorithmic
trading)
• Gaming (multi-player)
• Analytics & monitoring
• Marketing automation
• Systems integration
• IOT (healthcare, transportation, security)
When to Use Akka.NET

38. What’s in it for me?
Promises
Actors can’t be accessed
directly, only through actor
references.
Actors work by
asynchronously processing
strongly typed messages.
Actors process messages
serially and in FIFO order.
Benefits
Implementation and location
transparency (S.O.C. and
scalability.)
Less code; automatic
concurrency.
Actor state is always thread-safe
and requires no locks.