Skip to content
Home » The Virtual Actor Model

The Virtual Actor Model

The Virtual Actor Model provides a straightforward approach to building distributed interactive applications, without the need to learn complex programming patterns for handling concurrency, fault tolerance, and resource management1https://www.microsoft.com/en-us/research/project/orleans-virtual-actors/.

The Virtual Actor model takes the well-known traditional (static) actor model to the next level by introducing dynamic (virtual) actor placement2https://gitlab.com/darlean/darlean/-/wikis/darlean-deep-dive#actor-placement-distributed-directory.

Actors

Within an actor model, whether it be static or virtual, actors are treated as the universal primitive of concurrent computation. In response to a message it receives, an actor can: make local decisions, create more actors, send more messages, and determine how to respond to the next message received. Actors may modify their own private state, but can only affect each other indirectly through messaging (removing the need for lock-based synchronization).3https://en.wikipedia.org/wiki/Actor_model

In traditional actor frameworks, it is usually preconfigured where (on which node in the system) actors live. When their parent process stops, the actors are typically unavailable until the precess restarts.

Virtual actors

In a Virtual Actor model, actors are capable of easily persisting their state4https://gitlab.com/darlean/darlean/-/wikis/Actors-&-Services, and the framework keeps a dynamic administration of which actor runs on which node. Should a node go down, the framework automatically reincarnates the actor on another node. Because the actors are by nature capable of persisting their state, reincarnation can occur without data loss (and almost without interruption of availability), provided that the actors properly implement their persistence logic.

Framework functionality

In addition to the above mentioned functionality, virtual actors platforms typically offer some or all of the following additional functionality:

  • Persistence. One or more data stores can be configured. Actors can use these stores to persist their state. Most frameworks provide a unified interface to several types of underlying stores, so that actors do not have to be aware of the kind of storage.
  • Timers. Actors can be invoked at certain moments. These timers are persistent (they survive system reboot).
  • Sequential action execution. It can be configured whether actions on a certain actor can be performed in parallel (the actor can process multiple actions at the same time) or sequentially (on after the other, no more than one action is in progress for a given actor). This greatly simplifies the actor implementation as it does not have to take concurrency into account.

Advantages

Advantages of the Virtual Actor model are:

  • Scalability. More actor instances can be provided by adding more nodes.
  • Availability. Should an actor node go down, the actor almost instantly reincarnates on another node without loss of state.
  • Upgradeability. Because of the aforementioned property of availability, actor frameworks provide robust, zero-downtime system upgrades by repeatedly starting a new node and stopping an old node, until all old nodes have been stopped. All actors now run on new nodes without noticeable interruption.

The following advantages apply particularly to Darlean:

  • Independency. Because Darlean comes “batteries-included”, it can be deployed without the need for auxiliary supportive systems like data stores and brokers, even in production.
  • Language interoperability. Actors can be written in any language that supports websockets. Because of how Darlean works, all of these actors can seemlessly communicate and cooperate.
  • Extendability. Due to the modular design of Darlean, new functionality (like bindings to auxiliary systems) are easily added without the need to recompile the entire framework.
  • Deployability. Darlean has a lot of flexibility in terms of deployment. It can be deployed as containers, on virtual machines or on bare metal. It can use the sidecar pattern with one runtime node next to each app node, or any other n:m relationship between runtime and app nodes. It is even possible to combine app, runtime and helpers into one single application and to deploy that once or more.

References