Microsoft Orleans – Why you should care

Today at //build 2014, Microsoft finally released their (code name) Orleans actor framework to the public. I want to briefly summarize Orleans here.

Orleans is a framework for writing highly scalable, fault-tolerant distributed systems for cloud environments and doing it simply. It is very much a “get things done” framework, designed for productivity. It’s an actor framework, but manages to hide that aspect – messages appear as async method calls and actors are called grains. Orleans is not just another actor framework, it is unique and I’ll try to elucidate here.

Orleans applications consist of a bunch of grain (actor) interfaces and classes. These grains communicate with each other by making async method calls and and await’ing the result – in typical C# fashion. Grains typically represent things such as users, tweets, products, or whatever domain entities exist in a system. Orleans differentiates itself from existing actor model systems such as Akka and Erlang/OTP in a few ways, to the point where it is not conventional as far as the actor model is concerned. Orleans implements “virtual actors”, which are:

  • Identified by type & id, where id is a long or a GUID – note that they do not exist in a supervisor hierarchy like Akka/Erlang actors do.
  • Instantiated when they are first messaged.
  • Have their state persisted to a backing store (pluggable, but the SDK includes Azure Table Service support) – somewhat similar to akka-persistence.
  • Eventually garbage collected when they are left idle.
  • Type-safe: actors message each other by grabbing an instance and make asynchronous method calls on them. They use a code-gen phase to accomplish this.
  • Failures in remote actors are propagated as local exceptions.

Key takeaways from Orleans:

  • Futures and actors can live in harmony: continuations can be scheduled on an actor just as if they were another message. This reduces the hazards which are present in Akka when using futures from within actors.
  • Actors do not need to sacrifice type safety, though this removes them from the traditional actor model. Akka also has typed actors. Scala has a powerful macro system which can be used instead of Orleans’ codegen phase.
  • Garbage collected memory/actors allows users to focus on what matters. The run-time manages actor lifecycles so that you don’t have to. Notice the parallel between virtual actors and virtual memory. Most programmers wouldn’t dream of ditching virtual memory and managed memory today.

In the future, I want to see Rx integration with streaming support – it’s the next logical step. ActorFx (another great actor framework, from Microsoft Open Tech) makes pub/sub a first class citizen.


ActorFx allows you to throw arbitrary actor code into a cluster at runtime. Actors can be written in JavaScript, Python, or a CLR language. Basically, you can throw closures into the cloud/cluster with ActorFx. If you squint, they’re reminiscent of the Spores proposed for inclusion in Scala. Actor state is replicated within a quorum within the cluster for high availability. They’ve made pub/sub a first-class citizen using Rx in order to reactively process streams of messages pushed from actors. The Akka team is taking inspiration from Rx in order to provide Reactive Streams in an upcoming Akka release – maybe it’s no coincidence that Roland Kuhn and Erik Meijer both taught sections in the Reactive Programming course.
You can find out more by watching this Going Deep episode on ActorFx.


Download the SDK (Preview) and the Samples.

Read the MSDN Blog post.

Watch Using Orleans to Build Halo 4’s Distributed Cloud Services in Azure.

If you’re really keen (as I clearly am), read these papers, particularly the last one: