# Concurrency Without the Pain: Introduction to Akka.NET and the Actor Model
The .NET platform's most recent major releases prominently feature improved concurrency tools and keywords, and that's no accident. In a world where developers are expected to build applications that are consistently responsive across a wide range of devices, user experiences, and workloads knowing how to take full advantage of the power of concurrent programming is essential.
But let's face it: even with nice tools like the TPL and async / await, multi-threaded concurrent programming has typically been a bottomless pit of despair, Heisenbugs, and lessons learned the hard way.
None of this is true with Akka.NET and the actor model: a powerful programming methodology that makes building concurrent applications easy, fun, and much more powerful than what we had before.
2. Modern CPUs: More Cores!
Source: Karl Rupp https://www.karlrupp.net/2018/02/42-years-of-microprocessor-trend-data/
3. Modern Software: Concurrent
• Can’t take advantage of multi-core
architectures without multi-threaded or
multi-process (concurrent) application
designs
• Industry best practices increasingly push
language and API designs to drive this:
– Task and Parallelism Library (TPL)
– Async / Await
– More native async APIs in standard and third
party libraries
8. Actor Model Origins
• Originally conceived in
1973 to build large, multi-
core applications.
• First implemented in 1986
by Ericsson. Powers
modern day GPRS, 3G,
and LTE cell networks.
• Later adopted by Internet
giants.
• Made popular again by
cloud computing.
11. Actors
• Actors are independent micro-processes.
• They are cheap, disposable, units of work.
• Each has its own state and resources that
can’t be shared or directly accessed from
the outside.
• They work by sending and processing
immutable messages to each other.
15. How Actors Make Concurrent
Programming Easier
• Since actor state is private and can only be modified
serially, it’s automatically thread-safe
– No locks, critical regions, or synchronization
mechanisms needed
• Actors process messages asynchronously
– Lots of actors can process messages simultaneously
– Scale up to take advantage of multiple CPUs
automatically
• Robust fault-handling model
– Parents supervise child failures
– Faults isolated to failing actor only
– Actor restarts are transparent and “not a big deal”
21. 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.
24. Akka.NET Modules
• Akka – core actor library
• Akka.Remote – cross-node actor deployment /
communication
• Akka.Cluster – elastic actor networks (HA)
• Akka.Persistence – event-sourcing, durable actor state &
recovery
• Akka.Streams – streaming workflows
• Akka.Cluster.Tools – cluster singleton, distributed pub
sub
• Akka.Cluster.Sharding – durable state partitioning
• Akka.DData – eventually consistent data replication
25. When to Use Actors (Generally)
• Building stateful applications:
– Applications that can’t be built reliably using a
database as the sole source of truth.
– Examples: real-time applications, IOT, trading,
monitoring, marketing automation, large-scale
data analysis.
• Building highly fault-tolerant applications.
• Just need better concurrency tools in non-
distributed applications.
26. Where to Learn More
• http://learnakka.net – Akka.NET bootcamp
• http://getakka.net/ - Official website
• https://petabridge.com/ - Blog and tutorials