Reactive Systems: Actor Model and Akka.NET

All the world's a stage,
And all the men and women merely players.
-Shakespeare  

This quote from William Shakespeare's pastoral comedy As You Like It, can be very helpful when describing Actor Model. In this post, we will see what an Actor Model is and how you can use it to build concurrent, distributed, and resilient applications.

Building concurrent applications, distributed applications, and robust resilient applications is hard. Making use of the Actor model using Akka.NET makes these things easier.

There are many things to consider when building reactive systems. The Reactive Manifesto describes the general characteristics of such a system at https://www.reactivemanifesto.org/ and Akka.NET adheres to the principles set forth in reactive manifesto.

Akka.NET frees developers from various underlying concerns of such systems. e.g. manually managing the threads and locks around share resources. Instead, higher-level abstractions like actors and messages help develop these systems easily. Akka.NET is based on AKKA (JVM).

The idea of this post to get started with this programming paradigm and same time have an appreciation of this model and framework which we can use today and build such important systems.

Applications Classes

Here are a few of the applications, which could be a potential candidate for actor model.

• Financial/Statistical
• Game Systems
• Social Media
• Telecoms
• Batch Style: Divide workloads between actors
• General services: Rest/SOAP, System integration
• Chat applications/Real-time notifications
• Traffic management/location
• Business intelligence/Data mining
• Internet of Things: e.g. Sensor data (i.e. actor for each sensor etc

Why Actor Model?

The first reason for using an actor model-based system is that it can help us simplify the building of scalable, concurrent, high throughput, and low latency systems. This also gives us the starting idea of the kind of applications we can build using the actor model. If your application requires one or more of the above-mentioned features, then it can benefit from this model.

High abstraction level is also provided by actor model. We can think of Actor model as object-oriented programming on steroids as it formalizes the interaction between actors through the use of massages.

Besides the above-mentioned benefits. Following are some of the other benefits as well:

• No manual thread management
• Higher abstraction levels
• Scale-up/Scale-out
• Fault tolerance and handling
• Common single architecture

Actors and Messages

Actors are the place where the work of our system is actually performed. They contain the processing code. A single actor on its own can’t do much, so we can communicate between actors using messages.

Actors

• One way to think about the actor model is with the phrase “Everything is an actor”. Within our actor systems, actor is the fundamental and primitive computational unit that has to perform work in the system. Actors are the building blocks of our system.
• Actors should perform small well-defined tasks within our system
• Every actor instance has an address
• Actors do not make direct calls to other actors code, they can instead tell other actors to perform tasks by sending a message (loose coupling)
• Actor instances are lazy until they receive a message
• ~300 bytes overhead per instance
• There are essentially four things an actor can do:
  • Receive and react to messages
  • Can create more actors
  • Send messages to other actors
  • Can change behavior for processing the next message

Different Parts an Actor has

• Incoming Message Mailbox
  • Messages sent to the actor get queued here for processing. The actor can then process these messages, one at a time
• Behavior
  • React to an incoming message and perform define action. This is the code we write to react to an incoming message in the mailbox
• State (the current state)
  • An actor can have state (UserId, Request ID, counter, current temperature, etc.)
• 0, 1, m Children
  • Actor can optionally have child actors. The actor is then responsible for supervising these child actors
• Supervisory Strategy
  • Related to above point how to handle faults in the child actors

Messages

• The other important component is message. In Akka.NET a message is a simple POCO class
• Messages can hold some data, which we can pass to Actors. Actors can change its state when responding to messages
• Message instances should be immutable
• The passing of messages is asynchronous

Actor Systems and Location Transparency

An instance of actor system contains our actors. These actors can send messages to each other (local actor). We saw a diagram of such system above.

We can have multiple actor system instances. In addition to sending messages to actors within the same actor system instance, we can send messages to other actors (remote actor) which exists in another actor system instances and these actor systems can be distributed across different machines.

Due to the location transparency feature of Akka.NET, we send message to local or remote actors in the same way. 

Actor Supervision Hierarchies

Actors can supervise other actors. If an actor has children, it is responsible to supervise those and hierarchy of actors is formed. Supervision hierarchies allow the system to not only deal with faults but become self-healing. 

Summary

As we have seen the benefits which actor systems provide. Akka.NET helps us build such systems in .NET. We can use all OOP goodness as well along with built-in mechanism for mailboxes, thread safety, error recovery, etc. With these capabilities in-hand we can build systems or part of systems which are high performing, reactive, and fun to work on.

People have developed very interesting applications using this framework. I will suggest to visit the following links for some more information and sample code. Also, I will try to build a complete system using actor model in upcoming posts.

Akka.NET works nicely with other technologies like SignalR, WebAPI, etc.

There are many approaches to messaging-based systems and Akka.Net is a powerful one and we can use this power to build these systems in a variety of domains. Here is one very basic Application that is using Akka.NET as its core, along with SignalR and Angular, and you can check it out on this link. If you have some questions, feel free to ask and I will try to answer those. Happy coding.

Other Links

• https://getakka.net/
• https://petabridge.com/blog/