6 ms·

Lots of developers today just assume that microservices = containers, and if you're already in containers, you must need Kubernetes, but, really, Service Fabric

Lots of developers today just assume that microservices = containers, and if you're already in containers, you must need Kubernetes, but, really, Service Fabric is years ahead of Kubernetes in lots of ways. If I were starting a major distributed systems project today that required serious uptime and scalability, I'd start on Service Fabric. And, yes, I know... whatever feature I could name from Service Fabric has some sort of open-source thing for Kubernetes from someone that probably/almost/kind-of/sort-of/some-assembly-required does the same thing as Service Fabric. Or I could just use Service Fabric, and not play the Kubernetes equivalent of "what's in your node_modules directory?" Microsoft has an existential-level bet on Service Fabric. It's 1) not going anywhere, 2) only getting better, 3) is already a better container orchestrator than Kubernetes, if that's all you want to use it for.

zamalek 8y ago
We have stuff running on SF in prod, using the SDK side of it and not the container-like capabilities. I have some counterpoints (but my team is also divided on SF). First-off, you mentioned micro-services. The mechanisms that support service and application versioning seem well-intentioned and well-designed. In many ways the mechanisms run counter to some of the key benefits of a micro-service architecture (especially surrounding decoupling development teams). If your latency is high, deployment times out. We had to use a remote desktop session to a VM near the cluster to deploy manually (solved with CI/CD). This impedes teams who are trying it out, when they are remote. It has a pretty hostile development experience. Before you can even open a project in Visual Studio, you need the entire SDK installed. "Which SF installer did you use?" was a frequent question in Slack, because there are a bunch of places where it resides. Whenever you add a project to your solution, you have to ensure that it targets x64 (not AnyCpu). Strange compilation errors abound if you don't. We get it Microsoft: the runtime only supports x64 - you don't have to enforce it to this degree. AnyCpu runs just fine on x64. It sounds like nitpicking, but it gets horribly frustrating. They do (or used to do) strange things their .targets files. It doesn't behave like the C# build system, with a very clear happy-path. I spent about a week working around $(MSBuildProjectDir) not working. I would fix this by making the entire thing nothing more than a Nuget package. Anyone can understand having to have an emulator installed to debug, but the project system is hostile. It's a big pity because the tech is amazing. I've personally started championing Orleans+Docker as a more friendly alternative, but as I said: others on my team adore it.
- megaman22 8y ago
  This echoes a lot of my frustrations trying to understand how I might migrate a relatively conventional on-premise system to ServiceFabric. The biggest problem imo, is that so very few people are using it, at least who talk about it, that this might be the first mention I've seen outside of MSDN, and I started looking hard at it three years ago or more.
- rraghur 8y ago
  We had a similar experience as well.. in our case, tried hard to like SF, but eventually moved out. The Dev experience is sub par and even with the one node cluster, things take a long time to come up. Also, the tooling that pushes for services to be in a single application means that boot up times are impacted negatively. SF's application model means that you can't just run it outside. One of the lead devs had previously got burnt with reliable collections (no way to have it write to an attached disk.. will only write to VM local disk.. reported to ms) and risk potential disaster if you have a cluster loss. Eventually ported to .net core and Orleans 2 on k8s and it's been a more pleasant experience.
  - algorithmsRcool 8y ago
    I'll add another voice on this exact same situation. Trying to get .net core app running on SF was extremely frustrating and confusing. K8s was a MUCH more natural experience. I was really disappointed in the tooling. The sfproj files were this incomprehensible mess. If the ui didn't quite work you are hosed. I would go on but I'm on mobile
    - qrli 8y ago
      Their VS extension and libraries are always lagging behind. It seems the team do not have enough resource on the dev tool side. But you could use `guest executable`, which has no dependency on their tooling. You can create exe with any language/stack.
      - algorithmsRcool 8y ago
jacquesm 8y ago
> If I were starting a major distributed systems project today that required serious uptime and scalability, I'd start on Service Fabric. I'd start with Erlang. The track record of Erlang for those parameters is just about unbeatable. And then there is the very careful way in which they deal with backwards compatibility, which is a major asset for any long lived project. If your projects live (or are intended to live) for a decade or more such details really matter.

zamalek 8y ago

We have stuff running on SF in prod, using the SDK side of it and not the container-like capabilities. I have some counterpoints (but my team is also divided on SF). First-off, you mentioned micro-services. The mechanisms that support service and application versioning seem well-intentioned and well-designed. In many ways the mechanisms run counter to some of the key benefits of a micro-service architecture (especially surrounding decoupling development teams). If your latency is high, deployment times out. We had to use a remote desktop session to a VM near the cluster to deploy manually (solved with CI/CD). This impedes teams who are trying it out, when they are remote. It has a pretty hostile development experience. Before you can even open a project in Visual Studio, you need the entire SDK installed. "Which SF installer did you use?" was a frequent question in Slack, because there are a bunch of places where it resides. Whenever you add a project to your solution, you have to ensure that it targets x64 (not AnyCpu). Strange compilation errors abound if you don't. We get it Microsoft: the runtime only supports x64 - you don't have to enforce it to this degree. AnyCpu runs just fine on x64. It sounds like nitpicking, but it gets horribly frustrating. They do (or used to do) strange things their .targets files. It doesn't behave like the C# build system, with a very clear happy-path. I spent about a week working around $(MSBuildProjectDir) not working. I would fix this by making the entire thing nothing more than a Nuget package. Anyone can understand having to have an emulator installed to debug, but the project system is hostile. It's a big pity because the tech is amazing. I've personally started championing Orleans+Docker as a more friendly alternative, but as I said: others on my team adore it.

megaman22 8y ago
This echoes a lot of my frustrations trying to understand how I might migrate a relatively conventional on-premise system to ServiceFabric. The biggest problem imo, is that so very few people are using it, at least who talk about it, that this might be the first mention I've seen outside of MSDN, and I started looking hard at it three years ago or more.
rraghur 8y ago
We had a similar experience as well.. in our case, tried hard to like SF, but eventually moved out. The Dev experience is sub par and even with the one node cluster, things take a long time to come up. Also, the tooling that pushes for services to be in a single application means that boot up times are impacted negatively. SF's application model means that you can't just run it outside. One of the lead devs had previously got burnt with reliable collections (no way to have it write to an attached disk.. will only write to VM local disk.. reported to ms) and risk potential disaster if you have a cluster loss. Eventually ported to .net core and Orleans 2 on k8s and it's been a more pleasant experience.
- algorithmsRcool 8y ago
  I'll add another voice on this exact same situation. Trying to get .net core app running on SF was extremely frustrating and confusing. K8s was a MUCH more natural experience. I was really disappointed in the tooling. The sfproj files were this incomprehensible mess. If the ui didn't quite work you are hosed. I would go on but I'm on mobile
  - qrli 8y ago
    Their VS extension and libraries are always lagging behind. It seems the team do not have enough resource on the dev tool side. But you could use `guest executable`, which has no dependency on their tooling. You can create exe with any language/stack.
    - algorithmsRcool 8y ago

jacquesm 8y ago

> If I were starting a major distributed systems project today that required serious uptime and scalability, I'd start on Service Fabric. I'd start with Erlang. The track record of Erlang for those parameters is just about unbeatable. And then there is the very careful way in which they deal with backwards compatibility, which is a major asset for any long lived project. If your projects live (or are intended to live) for a decade or more such details really matter.