> It was created by Microsoft Research and introduced the Virtual Actor Model as a novel approach to building a new generation of distributed systems for the Cloud era.
Okay, sounds like an academic, Microsofty take on Erlang's Actors? But from docs, sounds like it's at least used in practice at MSFT:
> Since 2011, it has been used extensively in the cloud and on premises by several Microsoft product groups, most notably by game studios, such as 343 Industries and The Coalition as a platform for cloud services behind Halo 4 and 5, and Gears of War 4, as well as by a number of other companies.
> Orleans was open-sourced in January 2015, and attracted many developers that formed one of the most vibrant open source communities in the .NET ecosystem.
Academically (And, to some extent, practically speaking) Orleans Virtual actors aren't the same as Erlang (or Akka) actors.
Major differences:
- Normal actors are pretty flexible, can work in local or remote contexts. Orleans is probably best described as Sharded Actors, It's a 'guided' implementation of Actors compared to Erlang or Akka where you are given a toolkit and have to build out what you intend to do.
- Orleans doesn't have any ordering guarantees. While this is not a firm requirement of the Actor model itself, both Erlang and Akka guarantee ordering between a given Sender-receiver pair (i.e. messages sent from A to C will be sent in order)
- Akka and Erlang have the concept of Supervision. i.e. An actor may have a child, and if that child crashes, the (parent) is notified and may choose how to react (restart child, don't restart child, crash itself)
- Orleans may allow more than one activation of the same grain at the same time. A stable and properly configured Akka Shard cluster will never have more than one of the same entity actor alive at a time.
- Orleans can magically scale out with the cloud (If you're running them on Azure.) Erlang/Akka you'll have to deploy your new nodes.
> Orleans doesn't have any ordering guarantees. While this is not a firm requirement of the Actor model itself, both Erlang and Akka guarantee ordering between a given Sender-receiver pair (i.e. messages sent from A to C will be sent in order)
Ordering has a performance cost. It needs to either be maintained at all levels, or reconstructed from unordered messages at a later point. Even something simple like an m:n thread pool scheduler can ruin ordering guarantees. My view (Orleans core developer) is this: if you want ordering, await your calls. That way, you are guaranteed ordering regardless of any message reordering that can occur in the scheduling or networking layers, or due to failure and recovery of a host. So you can choose when to pay that cost and when to reap the performance benefits of not paying it (by firing off multiple calls in parallel).
> A stable and properly configured Akka Shard cluster will never have more than one of the same entity actor alive at a time.
Likewise for Orleans, but the caveat of a "stable cluster" doesn't do much for users. "Stable cluster" falls apart frequently in real scenarios, which can be as simple as a single machine being abruptly restarted. Developers must account for the error scenarios.
> Akka and Erlang have the concept of Supervision.
Orleans does not have supervision, since each grain stands on its own (no hierarchy) and have an eternal nature (managed lifecycle). Grains are not destroyed when a method throws an exception: the exception is propagated back to the caller and the caller can use try/catch to handle the exception. This is similar to what .NET developers are used to, since regular objects are also not destroyed when a method throws an exception, and the caller is able to handle the exception. My belief is that this kind of exception handling is usually appropriate, since the caller has context which can be useful in handling the error. The developer can also write per-grain or global call filters which can operate on all calls and handle any exception, so if that's preferred, then it's available.
> Ordering has a performance cost. It needs to either be maintained at all levels, or reconstructed from unordered messages at a later point.
Yep, although it's not typically as bad as it sounds even in Akka/Erlang; TCP gets you most of the way there. It does however become a problem when want to try to scale 'out' (i.e. use multiple links for message prioritization, etc.)
> Likewise for Orleans, but the caveat of a "stable cluster" doesn't do much for users. "Stable cluster" falls apart frequently in real scenarios, which can be as simple as a single machine being abruptly restarted. Developers must account for the error scenarios.
For sure, Akka doesn't do it for you. I think one of the biggest yak shaves in setting up would be picking your partition strategy and making sure it works the way you intended. But, once you do it's fun to watch the metrics graphs move when you cut nodes. :)
> This is similar to what .NET developers are used to, since regular objects are also not destroyed when a method throws an exception, and the caller is able to handle the exception.
Yeah supervision can be a bit weird to explain properly.
It all goes back to that first point though; Orleans is a very guided implementation and has very nice, C#-like bindings. Akka is in my view (Akka.NET project contributor, have also written some frameworks and in-production business apps using) more of a 'Toolkit'. You can see this in the various modules that result from it, such as Akka Streams, Spray/Play. Lagom, etc. Use Orleans if you want to write distributed code in C# quickly and within it's constraints. Use Akka if you want to write distributed code or just a quick and dirty Message-passing Scheduler/kernel.
> - Orleans doesn't have any ordering guarantees. While this is not a firm requirement of the Actor model itself, both Erlang and Akka guarantee ordering between a given Sender-receiver pair (i.e. messages sent from A to C will be sent in order)
I thought Erlang only guaranteed that if the processes are on the same node. Is that not correct?
Huh. Never actually looked into HOW it worked in erlang, but basically it looks like it works the same way as Akka/AkkaDotNet; VM skates on top of the underlying transport's ordering guarantees.
For a long time I was curious how Akka Artery preserved message ordering for it's 'dedicated large message' lane. in short it really just means you are dedicating a specific TCP or Aeron connection dedicated to those actors, there's no magic ordering sauce underneath. (just a little disappointed to find that out, but appreciate the simplicity upon consideration.)
Yep. Erlang uses a single TCP connection between each pair of nodes. Older versions had problems with large messages blocking heartbeats (and other messages) for a long time, but that's been resolved last year in https://github.com/erlang/otp/pull/2133.
> A stable and properly configured Akka Shard cluster will never have more than one of the same entity actor alive at a time.
So you're telling me that during a network partition, Akka will somehow know that the entity actor is alive and well in (one of) the other partition(s) and won't start a new one?
As long as you configure things properly, yes. By 'configure things properly', basically make sure that your timeouts for the shard regions is longer than the time it takes to shut down the entities living on the node.
Also worth noting that depending on the pattern used to send to the entity, there is a possibility of dropped messages during such a case.
the actor model isn't erlangs, it's actually a surprisingly old idea ( 1973 ). The virtual actor model is an interesting spin on the idea that simplifies a few things.
Orleans itself is quite nice, I've used it a few times on some smallish things. Looking at using it in anger for a large distributed backend system in the nearish future.
I use it too much and it has caused consternation with both American and Egyptian colleagues. Not sure what to reprogram my brain to use because it’s pretty ingrained at this point.
Okay, sounds like an academic, Microsofty take on Erlang's Actors? But from docs, sounds like it's at least used in practice at MSFT:
> Since 2011, it has been used extensively in the cloud and on premises by several Microsoft product groups, most notably by game studios, such as 343 Industries and The Coalition as a platform for cloud services behind Halo 4 and 5, and Gears of War 4, as well as by a number of other companies.
> Orleans was open-sourced in January 2015, and attracted many developers that formed one of the most vibrant open source communities in the .NET ecosystem.