Orleans: Orleans x Service Fabric

[mvbaffa]

Hi,

Reading about Service Fabric in the Azure web site it seemed to that this is a similar to Orleans.

Read This: http://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-actors-introduction/

What is the real difference between them ?

Thanks in advance

[gabikliot]

Hi

Reliable Actors (also called Service Fabric Actors) is another implementation of the virtual actor model pioneered by Orleans, with different tradeoffs.

There are 4 major differences:
1) Orleans is open source while SF (Service Fabric) is not.
2) Orleans can run anywhere where .NET 4.5 can run and is not tied to any hosting fabric, while SF Actors are tightly coupled with SF and Azure. It can run with .NET 4.5 in AWS or GCP (Google Cloud Platform). Also, there is a desire to make Orleans CoreCLR compatible (https://github.com/dotnet/orleans/issues/29#issuecomment-97694888 and https://github.com/dotnet/orleans/issues/368). We expect that to be a very modest amount of effort. Orleans silos can also easily run as a SF stateless service, as has been demonstrated by @ReubenBond.
3) Orleans has been running in production since 2011 and powering some major services within Microsoft. SF Actors is a new implementation (as opposite to the Service Fabric itself).
4) Orleans and SF have made a number of different tradeoffs w.r.t. to a number of runtime issues, such as consistency/availability and more, although the documentation is a little light on some of that kind of details: http://azure.microsoft.com/en-gb/documentation/articles/service-fabric-reliable-actors-introduction/.

[mvbaffa]

I have discovered now that Service Fabric does not run on Windows 7.

I will be implementing a new application and I would like to decide which option to use: Orleans or Service Fabric.

My doubt is if Microsoft will maintain both.

Thanks

[ashkan-saeedi-mazdeh]

Disclaimer I'm a game developer and game development tools developer by profession and only worked on Orleans stuff from the manual and has been interested in concepts related to distributed programming as a hobby/general interest. I've known and followed Erlang and found out about Orleans later on when MS published the first papers about it.

As a few examples of tradeoffs.

• SF acotrs save all state after each method call but Orleans puts the control in hands of the developer.
• At least for now the storage providers for SF are limited (Maybe I'm wrong and new storage providers can be easily created and added to the SF hosting environment).
• Interleaving calls in Orleans are possible but it doesn't seem to be the case for SF acotrs.
• I am not sure but it seems Orleans concepts of streams are not directly included in SF actors.
• Orleans on the other hand is not specific to a hosting environment so doesn't have by default any of the upgrading and autoscaling properties of SF hosting environment, however as @gabikliot said, @ReubenBond created an Orleans setup as a stateless service.

[ReubenBond]

At least for now the storage providers for SF are limited (Maybe I'm wrong and new storage providers can be easily created and added to the SF hosting environment).

You can create your own using an API similar to Orleans.

[richorama]

I thought I saw somewhere in the SF documentation that you can enable
re-entrancy for actors, so interleaving is supported.

On 5 May 2015 at 09:35, Reuben Bond [email protected] wrote:

At least for now the storage providers for SF are limited (Maybe I'm wrong
and new storage providers can be easily created and added to the SF hosting
environment).

You can create your own using an API similar to Orleans.

—
Reply to this email directly or view it on GitHub
https://github.com/dotnet/orleans/issues/384#issuecomment-98994211.

[ashkan-saeedi-mazdeh]

Sorry guys for the inaccurate info. I should investigate more before posting the next time. I suddenly felt the urge to clearify things a bit , I read much about Orleans and played with it but did not investigate the SF too much.

[mvbaffa]

Hi,

As I told you I need some assistance to decide which one I will choose. You that have much more experience in Orleans could help me in some questions:

1) Can I deploy Orleans Actors on Promise;
2) Can I embed Orleans in a Windows Service. That is can I deploy my actors on Premise and embed my Orleans host;
3) I am not an expert in Erlang but I have developed some prototypes:
. How can spawn worker processes (actors) in Orleans;
. How Can I control and monitor the lifecicle of my workers;
. How can I develop a supervisor of my processes (actors) for fault monitoring (very important);
. Is there a Finite State Machine in Orleans, if not which library are you using.

Thanks in advance

[gabikliot]

1) yes, of course you can deploy Orleans Actors on Premises. See http://dotnet.github.io/orleans/Step-by-step-Tutorials/On-Premise-Deployment
2) Yes, you can embed Orleans in a Windows Service. Orleans is just a .NET library. So just like you can embed any .NET code as Windows Service, you can do the same with Orleans. https://github.com/dotnet/orleans/blob/master/src/OrleansHost/WindowsServerHost.cs is how to start Orleans as Windows process. You can embed that as Windows Service.
3) I am not an expert in Erlang either.
a) you don't directly spawn actors in Orleans. You don't directly create them. Instead we have a different concept of Virtual Actors, when we create them. You can read about it in our paper: http://research.microsoft.com/apps/pubs/default.aspx?id=210931. This greatly simplifies the programming, as you don't need to deal with a lot of issue that the runtime is doing for you now.
b) actor controls its own lifecycle.
c) We don't have a build in supervision model. It is not necessary with Virtual actors, since the runtime now provides reliability of actors, not the supervising code. One can still build a supervision hierarchy if he wants, by himself, based on actors and periodic heartbeats between actors or other way. We can discuss it in more details. But the main point is: you might not need to.
d) There is no Finite State Machine in Orleans. You can use what ever .NET library you can find.

Please notice that the last 2 points about supervision model and Finite State Machine do not belong to this issue. This is about Erlang vs. Orleans, not Fabric Actor vs. Orleans. Fabric Actor are based on Orleans's Virtual Actor model and thus also do not have supervision model. As far as I know they also don't have Finite State Machine.

Gabi

[mvbaffa]

Thank you very much to all of you. It was important to me your information.

[gabikliot]

Another important difference between Orleans and Fabric Actors is support for streaming, provided in Orleans via Orleans-Streams and is not (at least currently) present in Fabric Actors.

[gabikliot]

It is also important to note that an-unchanged Orleans application could be hosted as a service on Service Fabric. In such a setup one can take benefit from Service Fabric hosting and management capabilities, without compromising any of Orleans' features.
See more details here and presentation.

[SiqiLu]

@ReubenBond

At least for now the storage providers for SF are limited (Maybe I'm wrong and new storage providers can be easily created and added to the SF hosting environment).

You can create your own using an API similar to Orleans.

I read many documents about Service Fabric, but found nothing about create storage providers for SF. Could you please give some information about custom storage providers? Thanks.

[ReubenBond]

@SiqiLu just so I'm clear, are you asking about how to create a state provider for Service Fabric Reliable Actors, or Orleans? If the former, then you need to implement IActorStateProvider if the latter, then you need to implement IStorageProvider.

[SiqiLu]

@ReubenBond Thank you a lot. I want to know how to create a state provider for Service Fabric, But could not find any documents about that. But how to config the IActorStateProvider to the Service Fabric runtime?

[sergeybykov]

But how to config the IActorStateProvider to the Service Fabric runtime?

This is a question that belongs in the Service Fabric docs/forum.

[SiqiLu]

Yes. I am sorry about this.

[sergeybykov]

@SiqiLu No problem at all.

[gabikliot]

Orleans has been integrated and can now run on Service Fabric (#2542), hosting Orleans silo as Service Fabric stateless service.

[RehanSaeed]

I've been doing some research on this, here is what I found:

There is a wonderful blog post "Comparing Microsoft Orleans and Azure Service Fabric Actors" that just highlights the differences. There is also "Service Fabric vs Orleans".

The two posts are a little out of date. Service Fabric is also now open source. Orleans and Service Fabric can both run on .NET Core and Linux for cheaper hosting.

The summary seems to be:

Service Fabric Advantages

• Better rolling updates. During an upgrade old versions of Actors are given time to finish their work before they stop running.
• Provides it's own Orchestrator that can run Docker containers, random executables like ASP.NET Core websites etc. I'm not sure why I'd want to do this though or what advantage this provides?
• Provides a nice UI, showing cluster state.
• Has very good Microsoft Docs and official support. Orleans also has Docs

Orleans Advantages

• State is stored in external storage while SF uses the local disk. SF seems very limiting in this regard, what does it do if it needs to store larger amounts of information, well you throw more instances at it? This probably means that Orleans is cheaper to run, due to the fact that Azure Table Storage is as cheap as it gets and you can run with fewer silos (nodes).
• Orleans gives you control in deciding when to persist state, I'm assuming this gives it better performance.
• Streaming between actors or between actors and clients.
• Pub/Sub messaging between actors, as well as actors and clients which both support.
• Orleans Grains support re-entrancy, so again I'm assuming this gives it better performance.
• You can run Orleans on Docker Swarm or Kubernetes. Service Fabric itself has an orchestrator and is intended to be run as the host although I'm not sure if it can run in Swarm/Kubernetes itself.

In my humble opinion, I think the reason you'd choose either is cost savings over something like CosmosDB which is very expensive. In theory, because you would need more SF nodes to store large amounts of data, SF could be more expensive but that's just me theorizing. I'm still investigating but Orleans looks very interesting.