[jrbancel]

Disclaimer: I work at Microsoft, not on Service Fabric but I have built complex stateful services on top of Service Fabric.

As zapita said, Service Fabric now handles containers but I think it is just because containers became trendy and FOMO kicked in.

Where Service Fabric is decades ahead of the container orchestration solutions is as a framework to build truly stateful services, meaning the state is entirely managed by your code through SF, not externalized in a remote disk, Redis, some DB, etc...

It offers high level primitives like reliable collections [0], as well as very low level primitives like a replicated log to implement custom replication between replicas [1]. I feel that publicly this is not advertised enough and it is unfortunate because it is a key differentiator for Service Fabric that the competitors won't have for a while, if ever because it is a completely opposite approach: containers are all about isolation, being self-contained and plateform independent while SF stateful services are deeply integrated with Service Fabric.

[0] https://docs.microsoft.com/en-us/azure/service-fabric/servic...

[1] https://docs.microsoft.com/en-us/dotnet/api/system.fabric.fa...