Building concurrent applications is hard. Building distributed applications is hard. And building robust resilient applications is also 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 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 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 of 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 kind of applications we can build using actor model. If your application requires one or more of the above mentioned feature, 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 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 actor model is with the phrase “Everything is an actor”. Within our actor systems, actor is the fundamental and primitive computational unit that have 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 actor to perform task 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’ve seen an example 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 location transparency feature of Akka.NET, we send message to local or remote actors in 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.
Executive Summary
As we have seen the benefits which actor systems provide. Akka.NET help us to build such systems in .NET. We can use all OOP goodness as well along with built-in mechanism for mail boxes, 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 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 which is using Akka.NET as its core, along with SignalR and Angular http://gamesystem.azurewebsites.net/ . If you have some questions, feel free to ask and I will try to answer those. Happy Coding.