Although very similar on some level, Orleans and Service Fabric Reliable Actors seem to be two different beasts in many aspects. In this post I would like to do a quick comparison, so that you can choose the one that fits your needs best.


Orleans is a project, that started in Microsoft Research. Now, it has been made open source and is maintained by the community. If things being open source gives you more confidence in them (like me), this will be a big plus. However you don't have an option to get paid support from Microsoft. Orleans focuses on the actor framework and on hosting actors in a reliable and scalable manner within a cluster.

Service Fabric is a proprietary product at the time of writing, although people would gladly see it open sourced. But it is free to use at the moment. It's most convenient to use it in Azure, but you can also run it on your own infrastructure or in another cloud. Service Fabric is much more than actor framework - first and foremost it's a cluster management system. You can deploy almost any application executable to the cluster, provided you package it in a right format. Another feature is the replicated, highly available key-value storage. Added on top of that, there is a framework that lets you build actor based applications.

Operation environment

Orleans is .NET based. You can run it both on Windows and on Linux (mono). There is an ongoing effort to port Orleans to .NET Core also. There is no requirement as to number of machines you need, but for reliability's sake you will probably want more than one.

In order to use Service Fabric, you actually have to have a Service Fabric cluster running. The minimum number of machines is 3, but for production it's recommended to have at least 5 (because of replication). The publicly available version requires Windows. However Microsoft is also building one for Linux. Most probably you'll be able to deploy .NET Core based actors to Linux in near future, but right now it's in closed beta. Docs also mention Java. And add Docker support on top of that.

Actor implementation and API

Actor model implementation is the area where the two frameworks are very similar. In both of them, you'll find:

  • virtual actors without explicit lifecycle (you don't have to create them to call them)
  • Task based abstraction over asynchronous messaging between actors
  • timers and reminders
  • proxies as a way to reference actors
  • no explicit supervision hierarchy (something you'll find in Akka / Akka.NET)

Orleans also has some features unavailable in SF RA at the moment, like streams. Another interesting feature in Orlens, that is not available in SF RA, is the usage of immutability to optimize object copying.

State persistence

Both in Orleans and in SF RA, an active actor keeps its state in the memory. However there are some differences as to how the state is made durable and how / when it is retrieved from the storage.

In Orleans you have state persistence providers. There are some available out of the box for different storage systems: Azure Tables, SQL Server, Azure Blob Storage. They are pluggable, so you can roll out your own. The actor is responsible for telling the framework when to store the data, typically after each change in the state. In case the actor instance needs to be recreated, for example when it was migrated to another node or it was garbage collected due to inactivity, state provider is asked to get data for this actor instance. Plain and simple.

In SF RA you get to choose either memory-only or disk persisted state. Both options ensure you have at least 3 replicas in different fault domains - a primary and two secondaries. When machine crashes or the actor instance needs to be relocated, another replica becomes primary. Then SF takes care of creating new secondaries if their number is lower than expected. Disk-persisted actor instance can be garbage when unused, and then recreated in memory when it is needed again. The persistence is not pluggable, but I imagine you could use a custom state storage with a bit of coding, if you really wanted to. The secondary replicas can also be used for some read-only scenarios.


Orleans uses clustering for scalability and high availability. The cluster nodes ("silos") manage the membership and reliability with a shared storage (ex. Azure Table Storage or Zookeeper). In Orleans, actors run within a process of the silo. The silo process just references a library with actor implementations. It's a simple and efficient solution, but it also means, that in order to update the application, you have to bring the whole silo down. The update process is manual, unless you come up with your own automation mechanisms.

Service Fabric is also a clustering system, but it is capable of running almost any service in the clustered environment. For example, an actor based one. Basically what it does, is managing external processes. In the case of actor based service this means, that for each actor "type", there is a separate process hosting actor instances of this "type". You can update one actor type to a new version independent of the others, as they are separate services. Actually, the update story is very well-defined in Service Fabric:

  • cluster nodes are mapped to update and fault domains (similar to Azure Cloud Services)
  • automatic mechanism updates one update domain at a time
  • health of the application is monitored during the process, according to defined rules
  • if error condition is detected, there's an option to roll back the update process


Orleans has a Telemetry API and you can plug tracking systems like Application Insights or New Relic to gather and analyze the telemetry data.

Service Fabric makes heavy use of Event Tracking for Windows for telemetry. There is an option to integrate with ElasticSearch, but if you want to use anything else, you have to hand craft some code. This will probably change in the future, as Service Fabric will move towards supporting OSes other than Windows.


The Orleans documentation covers all main topics, but is a bit stale in some places. For example, the "getting started" tutorial contains some misleading information, that was true in the past, but now it only makes it harder to actually start using the framework.

Service Fabric documentation used to be a bit selective in the preview period. Now it has been updated and is quite comprehensive.


Of course there is no single correct answer to the question of which one you should pick. I'd say, use Orleans if you:

  • put more confidence in open source software
  • want to focus on the actors framework
  • want to start small, ex. with one VM
  • need a lot of flexibility
  • you're ok with crafting your own deployment mechanisms
  • you're ok with using external actor state storage

Choose Service Fabric Reliable Actors if you:

  • want something Microsoft branded, with full support and comprehensive docs
  • want to host a variety of services (regular exe's, as well as stateful and stateless services based on SF frameworks)
  • need the advanced automation of the update process
  • expect to hit the bottleneck of an external actor state storage and want to use the distributed state storage SF provides instead

About the author:

Marcin Budny

Team lead of R&D at BT Skyrise. Works with Intelligent Transport Systems (ITS), where he faces problems in terms of equipment and software. He is passionate about the architecture of applications, cloudcomputing and IT systems quality. He constantly searches for novelties on software development. Marcin specializes in .NET technology, however he looks for inspiration in other languages and platforms.

Next Post Previous Post

blog comments powered by Disqus