
Microsoft Orleans – An approach to building distributed applications in .NET - hitr
http://dotnet.github.io/orleans/
======
refulgentis
"actors are called ‘grains’,"

If you can write a sentence "X are called Y", and X is more well-known, drop
Y.

"You can then send messages to the grain by creating a proxy object, and
calling the methods: var grain =
GrainClient.GrainFactory.GetGrain<IMyGrain>("grain1"); await
grain.SayHello("World");"

var brain = BrainClient.BrainFactory.GetBrain<IMyBrain>("brain1"); await
brain.Say("WTF");

~~~
theprotocol
I share your sentiment.

I'd been away from .NET/C# for a few years and came back to find that they
dialed the abstraction level to 11.

I adore C# as a language but I find myself increasingly alienated by its
generally accepted coding style.

I find that Microsoft's products have extremely unintuitive naming schemes at
both a low level (language, standard libraries) and a high level (.NET product
word salad naming schemes, Office 365 referring to a diverse and inconsistent
range of products...).

The skeptic in me thinks that this may be an attempt at educational lock-in.

The lines between marketing and technology have definitely been blurred.

~~~
m_mueller
Seems to me all big software houses are affected of this in their long
standing products. You start a new thing and come up with a good name. 15
years with 17 product cycles down the line and you have a whole forest of
names that have some relation to this thing.

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?

~~~
rdtsc
They brought in very highly paid, smart engineers. Which have periodic
performance reviews. If they don't we "we designed and implemnted X, Y, Z
awesome new abstractions / features" everyone in the room bosses, employees,
higher ups, marking it going to feel let down. So, we have ever more features.

"Say, Steve, what have you been doing last year?" \- "Welp, just making sure
things work, fixed some bugs, documentation, took customer calls. The product
essentially works, people love it". "Wait, so we haven't shipped any new
features, hmm, ok...".

vs the response of "We implemented fizz, bar, quux features. We tore down old
zig and added zag instead. It is really the same as old zig, but now look
green and re-written with latest framework we saw in HN headlines". "Oh great,
you get a promotion and a raise".

I am being a bit silly, but it is only half-joking, it is how software
industry often works.

------
markpapadakis
Orleans is just fantastic.

343 Industries famously used Orleans for Halo 4 backend services
infrastructure. Caitie McCaffrey's presentation can be found here:
[https://www.infoq.com/presentations/halo-4-orleans](https://www.infoq.com/presentations/halo-4-orleans)

You may be interested in Obit (
[https://github.com/orbit/orbit](https://github.com/orbit/orbit) ). It is
inspired and based on Orleans, except it's written in Java. Similar concepts
and semantics. ( a BioWare project )

~~~
mohdmasd
Why not Akka/Akka.net? It looks more mature framework with bigger community
and you can find much more resources about it.

~~~
ryanjshaw
I've experimented with both; I've done some Akka.net training. My thoughts:

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...](http://getakka.net/docs/working-with-actors/handling-messages)).
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.

~~~
bad_user
In Akka you can have typed actors, however you're missing the point.

In the actor model you often end up modeling state machines, and especially in
the presence of asynchrony, it is impossible to meaningfully add types to such
state machines. Because you see, the full set of messages that an actor
recognizes at some point is much less interesting than the set of messages an
actor accepts right now.

Another problem is that actors often communicate with multiple other actors at
the same time, possibly aggregating data from multiple sources, outputting
data on multiple channels. Thus a single actor can expose different APIs,
depending on whom it is taking to.

And yet another problem is that often actors act as proxies or supervisors,
simply forwarding messages around.

Basically people complaining about the untyped nature of actors are terribly
misunderstanding the actor model. Or distributed systems.

~~~
jamesblonde
You don't add types to state machines, however you can add typed ports and
channels to actors. There is no requirement for a single inbox for messages.
See kompics
[http://www.springer.com/la/book/9783642450648](http://www.springer.com/la/book/9783642450648)

------
tpetricek
For those interested in distributed, high-scale computing on .NET, I'd also
recommend having a look at MBrace: [http://mbrace.io/](http://mbrace.io/)

MBrace supports F# and C# and is designed to work well in interactive
scripting scenarios, which lets you develop scalable systems gradually using
REPL. I think it is complementary to Orleans/Akka.Net, so it is worth knowing
it exists!

------
0xmohit
Comparison of Orleans with Erlang and Riak Core:

[http://christophermeiklejohn.com/papers/2015/05/03/orleans.h...](http://christophermeiklejohn.com/papers/2015/05/03/orleans.html)

------
hitr
I did not know about this until I looked at the awsome-dotnet list[1] .This
project is based on Microsoft research[2] and is heavily used internally and
externally at Microsoft (Halo and Skype project). I think the Microsoft Azure
Service Fabric is cloud version of the orleans might be originated from this
framework(I may be wrong).I have done some sample applications and i think
this is a good alternative to AKKA.NET

[1][https://github.com/quozd/awesome-dotnet](https://github.com/quozd/awesome-
dotnet) [https://www.microsoft.com/en-us/research/project/orleans-
vir...](https://www.microsoft.com/en-us/research/project/orleans-virtual-
actors/)

~~~
reubenbond
> I think the Microsoft Azure Service Fabric is cloud version of the orleans
> might be originated from this framework(I may be wrong)

Service Fabric is a confusing beast. It _includes_ a Virtual Actor runtime
which is indeed very heavily inspired from Orleans, but it is a
reimplementation. Orleans is built for "cloud" scenarios. You can run Orleans
on top of Service Fabric using a host I wrote:
[https://github.com/OrleansContrib/OrleansFabricSilo](https://github.com/OrleansContrib/OrleansFabricSilo)

------
swalsh
Why does Microsoft keep doing this, over and over again a technology becomes
big, and Microsoft says "learning x is hard, we developed Y so you can do X
without learning it". Which sounds good on the surface, but the trade off is
1. You can't leave the platform and reapply the concepts... you're stuck in
Microsoft, but even more importantly 2. The process of abstracting away the
thing you're trying to avoid learning means that you're probably doing it less
efficiently.

~~~
reubenbond
In this case you can: Orbit (by Bioware/EA) for the JVM also implements the
Virtual Actor model. Hopefully other frameworks will adopt the model, too.
Orbit: [https://github.com/orbit/orbit](https://github.com/orbit/orbit)

------
joostdevries
I myself am mostly aquainted with Akka for Scala. So I was wondering what
different design decisions they made, if any. After all a second
implementation of a framework is often better than the first.

They do go into that in the research paper [1].

"Actor platforms such as Erlang [3] and Akka [2] are a step forward in
simplifying distributed system programming. However, they still burden
developers with many distributed system complexities because of the relatively
low level of provided abstractions and system services. The key challenges are
the need to manage the lifecycle of actors in the application code and deal
with inherent distributed races, the responsibility to handl e failures and
recovery of actors , the placement of actors, and thus distributed resource
management. To build a correct solution to such problems in the application,
the developer must be a distributed systems expert. To avoid these
complexities, we built the Orleans programming model and runtime, which raises
the level of the actor abstraction."

It's an interesting question how hard it would be to offer such a often-good-
enough option in Akka for the cases when you don't have the need or the time
or the team to develop a custom distributed computing model.

Edit: maybe Lagom is meant to fit that space. I think it's wider in scope than
'easy actors' though.

~~~
joostdevries
For posterity's sake: I just noticed this thorough comparison between Akka and
Orleans from the Akka team. [1]

[https://github.com/akka/akka-
meta/blob/master/ComparisonWith...](https://github.com/akka/akka-
meta/blob/master/ComparisonWithOrleans.md)

------
jsingleton
I saw a talk about how this was used in Halo. Seems very impressive but I
haven't had a project that needed this sort of scale since then. They are
working on supporting .NET Core, which is promising:
[https://anclafs.com/#other](https://anclafs.com/#other)

 _Shameless plug:_ I wrote about this in chapter ten of my recent book
([https://www.packtpub.com/packtlib/book/Application%20Develop...](https://www.packtpub.com/packtlib/book/Application%20Development/9781785881893/10)).
You'll need to have bought it for that chapter, but the first one is free.

~~~
jpalomaki
Talk from Build 2014: "Using Orleans to Build Halo 4’s Distributed Cloud
Services in Azure"
[https://channel9.msdn.com/Events/Build/2014/3-641](https://channel9.msdn.com/Events/Build/2014/3-641)

------
youdontknowtho
Service Fabric is a system that came out of this research. It's in use now by
some game companies and Microsoft uses it as the platform that they build
their offerings for Azure on.

[https://azure.microsoft.com/en-us/services/service-
fabric/](https://azure.microsoft.com/en-us/services/service-fabric/)

It's really slick. Persistent distributed .Net collections. Actor model
support.

[https://channel9.msdn.com/Events/Build/2015/3-618](https://channel9.msdn.com/Events/Build/2015/3-618)
Service Fabric stuff starts at ~38 minutes in...

[https://channel9.msdn.com/Events/Build/2016/KEY02](https://channel9.msdn.com/Events/Build/2016/KEY02)
Scott Hanslemann demos its use for a game called Age of Ascent? (Something
like that.)

In addition to being in production use in Azure for several years it also runs
on Linux.

------
Rapzid
It's been a couple years since the last time I looked at Orleans. I must say
though that even in the early days the documentation was pretty good; it's
even more impressive now.

------
tangue
Why this name ? As someone who has family in this town I'm wondering.
Historical reasons ? Some character in a game I don't know about ? Random
chosen french city ?

~~~
reubenbond
Back when this was an internal MS project (and I was working there, on another
team), I believe the icon for the Orleans (internal) nugets and the demo apps
was the Mardi Gras flag, which suggests that it's named after New Orleans. I
might be misremembering.

------
agumonkey
I thought MS Nancy was firstname based, but I'm starting to wonder if they're
revisiting "USofA oldest ally".

------
jimmcslim
The latest episode of Scott Hanselman's podcast covered Orleans in an
interview with Richard Astbury.

[http://hanselminutes.com/536/exploring-the-orleans-
distribut...](http://hanselminutes.com/536/exploring-the-orleans-distributed-
virtual-actor-model-with-richard-astbury)

------
UK-AL
Whats the difference between service fabric and this?

~~~
nimish
Service fabric is a different distributed runtime with its own complex
semantics. Orleans is conceptually simpler, with (virtual) actors running on
"silos"; it's much closer to erlang.

------
revelation
What's up with the string identifiers? Don't break refactoring, that's just
Java-esque.

