Microsoft Orleans – An approach to building distributed applications in .NET

See also:

iTunes (OSX), iTunes (iOS), "Music" (iOS), Apple Music, iTunes Match, Genius and the iCloud Music tab. Podcasts and videos are also all in there somewhere, know what dear user, you figure it out k?

Let's break the problem down.

You have a language that doesn't natively support actors or message passing. You can solve this by having the developer stub each method (`this.DispatchActorMessage(...)`) or you can implement the interface on behalf of the developer (`Factory.CreateProxy<T>()`). Microsoft doesn't always use the runtime emit approach and, as someone who has used both approaches[1][2], runtime emit is far preferable. This means that something in your code has a responsibility to create actor proxies. That's the first concept: the responsibility to create actor proxies. Not only that, but so far as Reliable Actors go the proxy needs to do quite a bit of work: actors can be rescheduled to another machine and the proxy needs to continue representing that single durable instance.

You also have context: "which cluster controls this actor?" Depending on your scenario you might be able to assume that there is no context. Microsoft cannot make these assumptions because federation is quite important in the enterprise. In fact, the ability for Reliable Actors to have context [will] allow our customers to extend our product without us worrying about noisy neighbors (they are in charge of their own actor cluster, we simply federate to it). Additionally, there are scenarios where the consumption of an actor occurs outside of the context. For example: calling an actor from a GUI app.

In order to create the actor, you're going to have to use the object with that responsibility (unless you fancy doing the emit yourself): `ActorFactory.Create<IBrainActor>()`. You then need to pass in the context. Orleans uses a `Client` instance (which should make sense to .Net developers), while Reliable Actors pass the context into the `Create` method. So either: `Context.Factory.Create()` or `Factory.Create(Context)`. Nothing more than a stylistic choice necessitated by the requirements that Orleans and Reliable Actors don't share.

The goal here is not to replicate Erlang. It is to make a framework where developers can write distributed systems with a low amount of ceremony. Actors so happen to be the best candidate as a primitive but are most certainly not the be-all and end-all of Reliable Actors (which were inspired by Orleans, so I assume the goal is the same for Orleans). In that way, it makes some things far simpler than Erlang[3] but there's always a cost to that. If distributed systems is the primary goal, then you're going to have overhead if you are not creating a distributed system.

If you're talking about terrible naming, that outright I can agree with. Orleans, however, is no more and no less abstracted than it needs to be.

[1]: https://msdn.microsoft.com/en-us/library/system.diagnostics.... [2]: https://azure.microsoft.com/en-us/documentation/articles/ser... [3]: http://erlang.org/doc/reference_manual/distributed.html

Not to mention that the standard OO cult of unit test / mock everything and make everything "reusable" leads to such shitty designs that almost fall out naturally from the language/paradigm. Oh and the one class per file with 3 method interfaces and 10 ceremony lines with namespaces and import definitions/braces.

I prefer C# over Java, and in some cases even over F# (it's slightly lover level and therefore it's simpler to control for things like heap allocation) but it usually is that verbose and crazy in the real world from my experience.

Otherwise it's just

await grain.SayHello("World");

   do! GrainPid <! "HelloWorld"

stilll a bit more verbose than erlang though

I'm not sure claims to Akka.NET's maturity hold water relative to Orleans. Akka proper has a lot of miles on it, but so does Orleans, and I'm not sure Akka.NET is as heavily tested and stressed as Orleans.

1. Orleans is very clean but highly opionated and this results in what I see as operational shortcomings, e.g. I prefer running discrete Windows services that I can start/shutdown to provide fault isolation and safe upgrades, but this doesn't seem to be directly supported in Orleans (the documentation speaks about "restrictive placement strategies" to ensure certain grains are located in certain silos, but I could never figure out how to achieve that, and it also seems against the design to have such a level of control). If it fits what you need, it's really a nice solution.

2. Akka.net's API is very messy and out-dated, in my opinion; I'll give some examples. You have to inherit from Akka.net classes, which makes me very nervous from a testing standpoint. Messages are untyped. There is no easy way to understand the interface (sequence of valid message flows) to an actor. This suggests maintenance will be tricky after some time away from the code unless you carefully design your actors (yes, arguably this could be said of any code). Documentation for fundamental topics is still incomplete in places (e.g. http://getakka.net/docs/working-with-actors/handling-message...). Persistence still confuses me after reading it 5 times. That all being said, it's a straightforward API clone of something that is proven and accommodating to the different development styles required for a broad range of back-end services.

These questions add nothing to the conversation beyond a veiled promotion of someone's pet technology