Documentation: No documentation on how orleans relate to Azure Service Fabric

[ashkan-saeedi-mazdeh]

It is a good idea to add a documentation page for configuring Orleans to be used inside SF but about how it relates to, I'm not sure since Orleans's relation to SF is similar to its relation to any other membership and storage provider. SF is a micro service management and orchestration platform which has an actor model implementation inspired by Orleans and there is no other specific relation.

Can you clarify about what exactly you want in the docs?

[Bartolomeus-649]

If there is a way to use Orleans inside Service Fabric, than that should be documented.

And if " SF is a micro service management and orchestration platform which has an actor model implementation inspired by Orleans and there is no other specific relation." than that should be documented as well.

When there are two .NET technologies that do about the same thing and they kind of both are Microsoft stuff, then their relations should be clarified.

[ashkan-saeedi-mazdeh]

@ReubenBond is the guy who worked on the integration. Reuben is anyone using it who can help writing the docs? I can not do so since I didn't use it and only looked at SF briefly back then.

[ReubenBond]

@ashkan-saeedi-mazdeh there are certainly consumers using these bits. I should probably write the docs, though - unless someone wants to volunteer.

[sergeybykov]

@Bartolomeus-649 Have you found the sample - https://github.com/dotnet/orleans/tree/master/Samples/ServiceFabric?

[asifshiraz]

I would second the need for such documentation. But beyond documentation, (whose scope I believe would be to demonstrate how to run Orleans on top of SF, or an objective comparison of their features), what I would like to know as a new user, is the long term vision for both of these similar products. It is a fine fact to know that SF actor model is inspired and indebted to the success of Orleans, but its existence appears to be competing for the attention of a new user looking for an actor model implementation on Azure. With the interest that SF is generating, (I hear of three conference rooms with standing attendees for SF sessions at Build), it seems that users would simply opt for an actor model that comes bundled with SF, tightly integrates with Azure, and promises to be using the best lessons from Orleans, then to go with an application layer implementation of the actor framework. SF is some key features behind Orleans I believe (like streaming, fault-recovery etc.), but it would probably be a matter of time when SF actor framework catches up. What then, would remain to be the special appeal of Orleans in comparison to SF, when a client has already decided on platform Azure.

[gabikliot]

Tightly Integrated can sometimes be an advantage, but is not always better. Light, flexiable, pluggable architecture may be a better choice, especially in a nowdays agile world of fast-pace technical changes. Plus open source of course: an ability to quickly fix a framework bug.

A real and trustable comparison (in my humble opinion) can only come from the customers. Customers/users should speak. That is, if you could use both and compare and write your opinion, that would be more valuable I believe.

[sergeybykov]

@asifshiraz The vision for Orleans is simple - open platform for building scalable apps/services that run anywhere you want, the way you want. We built it for internal users and later shared with everybody. We plan to keep doing so with new features and improvements being added or a regular basis. Some of them come from our continuing collaboration with Microsoft Research (geo-distribution, transactions). We'll continue to invest in the platform, so long as it has value for its internal users. And we share it with everybody in a transparent manner, so that other can benefit from it and contribute to it.

Even though the majority of Orleans users appear to be using it on Azure (it is hard to have an accurate statistic of that), we also have users running it on AWS, GCP, and private clusters.

[kogir]

I specifically chose Orleans because it performs well in our tests, is easily deployed correctly, and preserves the option to run easily on premises or other clouds (though I am currently using Azure).

It may say more about me than Service Fabric Reliable Actors, but I spent a full week trying to get SF deployed correctly with certificates and Azure AD integration before giving up without succeeding. I couldn't even evaluate it in the time allotted. I had Orleans running on Cloud Services in a private VNET in less than a day.

At least until the SF tooling improves, for me the choice was easy to just use Orleans and get back to getting actual work done instead of fighting brittle Azure RM JSON. Now that I've run it in production and interacted with the team on GitHub and Gitter, I have no plans to look elsewhere later either.

[ashkan-saeedi-mazdeh]

@sergeybykov Your comment indirectly is another value of Orleans :) You'll maintain if it has a value for internal needs of teams at MS but it will be always available to maintain but SF will only be something reliable until the day MS thinks it should be and then might be open sourced without any open source community.

Most important of all the partitioning issue @galvesribeiro talked about on gitter is very important. In Orleans we don't have limitations of SF and one doesn't have to predefine partition.

[gabikliot]

@galvesribeiro , can you link to the partitioning discussion from gitter here? Or just explain it here. Thanks.

[ReubenBond]

Closing this for now. We can open it again if there's anything to add.