Comparing .NET virtual actor frameworks

Orleans

The Orleans framework is the precursor of virtual actor model. It comes from a Microsoft Research project started in 2010. It powered backend services of well-known games like Halo 4. Back when it started, it was a little rough around the edges, with static classes, a lot of reflection, XML configuration etc. However now, a few iterations later, it is rather pleasant to use.

Orleans focuses solely on the virtual actor model - the traditional actor hierarchies are not explicitly supported.

Orleans implements its own clustering mechanism and relies on external database to provide membership information to the cluster members. Orleans also has its own code generated serializer for remote messaging (although serializers are pluggable). Similarly, the network protocol is specific to Orleans.

Pros:

 Cons:

Akka.Net is a port of the Akka project from Java ecosystem. It is a project under .NET Foundation, backed by the Petabridge company. It has an open-source core and tools and services offered as commercial addons.

Being a close port of another framework, Akka.Net brings all the good ideas from the original, but also brings controversial design decisions (e.g. HOCON configuration).

Akka.Net focuses mostly on the use case of traditional actors and supervision hierarchies. But it also has the clustering module that can create actor systems across multiple machines. In particular, the Cluster Sharding mechanism resembles the virtual actor approach. The main difference from the user perspective is that Akka.Net does not deal with single virtual actors. It rather groups them into shards according to user-specified sharding strategy and then assigns those shards to machines in the cluster. It has some unique solutions in this regard, which will be discussed in another blog post.

Akka.Net follows the route of implementing its own clustering mechanism as well as network protocol and serialization (it’s possible to swap out implementations). Although out of the box version 1.4 uses Newtonsoft JSON serializer, our tests show that better performance can be achieved using the Hyperion serializer (currently in beta).

Pros:

Cons:

Proto.Actor is a framework founded by the creator of Akka.Net. It incorporates the learnings from Akka.Net, but at the same time it makes “do not reinvent the wheel” its main philosophy.

This means that aspects like serialization, messaging and clustering all reuse existing and battle tested solutions. In particular, Proto.Actor makes use of gRPC with protobuf. It also uses existing clustering providers like Consul, Zookeeper or even the native Kubernetes APIs. You can select the implementation that fits your use case and your infrastructure.

The virtual actors are a first-class concept in Proto.Actor. There are many ways the framework supports this programming model, including code-generated base classes that encapsulate low level communication concerns. At the same time, it is also possible to create traditional supervision hierarchies. These approaches are easy to mix and match in Proto.Actor.

Proto.Actor also provides an interesting mechanism called Local Affinity, which we will explore in a later blog post. Another differentiator is the Go version of the framework.

Pros:

Cons:

Dapr is another open source project backed by Microsoft. It is a broader framework, that delivers service discovery, secure and reliable communication between services as well as abstractions over storage and pub-sub functionality. But one additional part of Dapr is the virtual actor model implementation with some concepts borrowed from Orleans. 

Dapr implements its functionality in a technology agnostic way. The framework itself is written in Go, but it runs next to the actual application (e.g. in sidecar container) and it communicates with it via HTTP or gRPC calls. This is interesting because you can build an actor-based solution with any technology. However, the Dapr runtime does not take care of a crucial aspect - actor’s state. The actor should keep its state in memory and only interact with persistent storage when needed. If you use one of the Dapr SDKs, the state will be cached for you in memory, otherwise you must implement a similar solution yourself.  

On the downside, the sidecar approach introduces overhead. It seems, that Dapr’s virtual actors implementation is not meant for high throughput scenarios. 

The showcase application, eShopOnDapr, uses virtual actors to implement a persistent workflow (Process Manager pattern) which is an interesting use case. 

Pros: 

Cons: 

The virtual actor frameworks available in .NET ecosystem often offer unique features. There is no clear answer to which one is the best, because as usual - everything depends on the use case.  

To dig a little bit deeper into some of these frameworks, we will compare their performance and cluster topology change handling in the upcoming blog posts. 

Marcin Budny, R&D Lead

Marcin is a software architect and developer focused on distributed systems, cloud, APIs and event sourcing. He worked on projects in the field of IoT, telemetry, remote monitoring and management, system integration and computer vision with deep learning. Passionate about latest tech and good music