Service-fabric: Are there any plans to integrate Orleans more deeply with SF?

[KTazayan]

For example to be able to choose between SF Reliable Actors and Orleans. I know that Orleans team is working on it but IMHO it still in beta and doesn't work properly.

[vipul-modi]

Service Fabric is a comprehensive platform, we respect and encourage different programming model choices the customers have. The Reliable Actors uses and showcases all the platform features like partitioning, failover, name resolution, load balancing, security, local state, zero downtime upgrade and others.

While the Reliable Actors used all the public features (except transport) of the platform; now that the platform us open sourced, we expect deeper integration of other framework and programming models. Additionally, we expect that community driven newer programming models to come up as well that uses and showcases platform features in more novel ways.

[petroemil]

Orleans is designed to be quite flexible when it comes to platform integration and the various storage providers. In theory they could provide the same level of integration to the underlying Reliable Services "runtime" as Service Fabric's Reliable Actor implementation, but still without being strictly tied to Service Fabric (it can run as a self-hosted service or in Docker containers as well).

At this very moment, Orleans is also more feature-rich as an Actor framework than the Reliable Actors, featuring distributed transactions, Streams and more.

So really the question is: are these two very similar Virtual Actor frameworks going to be developed by Microsoft side-by-side, or is there a plan to merge them?
If these two frameworks will co-exist, which one will Microsoft build its future frameworks on top of?

[vipul-modi]

All the customers of Service Fabric including internal customers have the same choice of programming models when they run on top of the platform. As mentioned previously the goals of reliable actor and reliable services (including reliable collections) is to directly leverage the platform functionality without additional layering. They are built for the Service Fabric platform. We, along with the community contribution will continue to work on closing any feature gaps that leverage the platform functionality.