5 ms·

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

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
      Yes, this is what I had to do because of .Net core. I still had some trouble getting the cluster to deploy smoothly. But honestly, K8s has first class support from MS, Google, AWS. Has major buy-in from the community, good docs, plenty of recorded talks, presentations and war stories and a very active community. SF has basically none of that. At the end of the day, SF isn't massively better than K8s for my use case and It would have to be to make up for all those disadvantages.
    - masnider 8y ago
      (Hey folks, I'm Matt Snider, I work on the SF team at Microsoft. If you've been in one of our community calls or hung out in our slack, you've probably encountered me. If not, hello!) I think it's absolutely correct that the tooling for SF has been rough to use. Especially at the beginning we were running into many issues related to the transitions between VS2015 and 2017, different project systems, changes in .NET/.NET Core, and our own lack of understanding about how the tools should work (I used to joke that I'm the PM that lives furthest from UI). We had the luxury of being not-as-good at tools when we were just an internal thing at MS because other teams would pick up that slack. They were pretty forgiving, but that let us think that we had the development story figured out. We most definitely did not. When the real VS org got involved before we announced the product publicly, it made a world of difference and I think some of us started to realize how much our previous experience sucked. It has taken us a while to learn how people actually want to develop on top of this thing in the real world and to climb out of that pit, building experience as we go. In the last few months things have gotten better. There's still lumps (deploying many services to my dev box is still way slower than I'd like), but there's also been some improvements. We've made the transition to tools that are included in VS2017 by default (rather than having to download and maintain them separately), and made sure our APIs support .NETCore/Standard. Some of the MSBuild weirdness is still around (like whatever this is[1]) but overall the environment is much more stable and that's helping tremendously. We've also made some SF specific changes around supporting what we call "Application Refresh Mode" and a single node local box experience (rather than making you run a whole 5 node cluster on your dev machine and doing full upgrades all the time, which can be more taxing). These things help speed up the hack-build-run dev cycle. Most recently we created a whole new FabricClient[2] which is self contained and works over just http. This is a big change and fixes some of the things mentioned in this thread (like having to have the SDK somehow installed on your build machines just to deploy to a cluster). Plenty of room left to improve in the tooling and improve the product overall. Thanks to folks for their comments - again this sort of feedback is really useful. I try to read the HN comments when we get our stuff posted here and pull out tidbits, but you can also just open up items in our GitHub issues list[3], which gets triaged fairly frequently. [1]: https://github.com/Azure/service-fabric-issues/issues/1095 https://github.com/Azure/service-fabric-issues/issues/1095 [2]: https://blogs.msdn.microsoft.com/azureservicefabric/2018/05/22/new-service-fabric-client-library-for-net/ https://blogs.msdn.microsoft.com/azureservicefabric/2018/05/... [3]: https://github.com/Azure/service-fabric-issues/issues/ https://github.com/Azure/service-fabric-issues/issues/
qrli 8y ago
I have always avoided its VS project extension. If you do only `guest executable`, it is super intuitive and you can simply create any kind of exe with any language/stack. The package can be created by a few lines of PowerShell scripts, which is much simpler and more stable than its VS extension. Of course, the stateful service feature is lost. But k8s does not have that feature either. Till now, I see its `guest executable` solution a good balance.
- algorithmmonkey 8y ago
  > Of course, the stateful service feature is lost. But k8s does not have that feature either. Persistent Volume Claims go a long way toward the stateful service "feature". To go another step further on stateful services, SF's stateful services are only supported in a couple languages. Where mounting a volume in K8s which will follow your container is pretty darn accessible to any language.

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
    Yes, this is what I had to do because of .Net core. I still had some trouble getting the cluster to deploy smoothly. But honestly, K8s has first class support from MS, Google, AWS. Has major buy-in from the community, good docs, plenty of recorded talks, presentations and war stories and a very active community. SF has basically none of that. At the end of the day, SF isn't massively better than K8s for my use case and It would have to be to make up for all those disadvantages.
  - masnider 8y ago
    (Hey folks, I'm Matt Snider, I work on the SF team at Microsoft. If you've been in one of our community calls or hung out in our slack, you've probably encountered me. If not, hello!) I think it's absolutely correct that the tooling for SF has been rough to use. Especially at the beginning we were running into many issues related to the transitions between VS2015 and 2017, different project systems, changes in .NET/.NET Core, and our own lack of understanding about how the tools should work (I used to joke that I'm the PM that lives furthest from UI). We had the luxury of being not-as-good at tools when we were just an internal thing at MS because other teams would pick up that slack. They were pretty forgiving, but that let us think that we had the development story figured out. We most definitely did not. When the real VS org got involved before we announced the product publicly, it made a world of difference and I think some of us started to realize how much our previous experience sucked. It has taken us a while to learn how people actually want to develop on top of this thing in the real world and to climb out of that pit, building experience as we go. In the last few months things have gotten better. There's still lumps (deploying many services to my dev box is still way slower than I'd like), but there's also been some improvements. We've made the transition to tools that are included in VS2017 by default (rather than having to download and maintain them separately), and made sure our APIs support .NETCore/Standard. Some of the MSBuild weirdness is still around (like whatever this is[1]) but overall the environment is much more stable and that's helping tremendously. We've also made some SF specific changes around supporting what we call "Application Refresh Mode" and a single node local box experience (rather than making you run a whole 5 node cluster on your dev machine and doing full upgrades all the time, which can be more taxing). These things help speed up the hack-build-run dev cycle. Most recently we created a whole new FabricClient[2] which is self contained and works over just http. This is a big change and fixes some of the things mentioned in this thread (like having to have the SDK somehow installed on your build machines just to deploy to a cluster). Plenty of room left to improve in the tooling and improve the product overall. Thanks to folks for their comments - again this sort of feedback is really useful. I try to read the HN comments when we get our stuff posted here and pull out tidbits, but you can also just open up items in our GitHub issues list[3], which gets triaged fairly frequently. [1]: https://github.com/Azure/service-fabric-issues/issues/1095 https://github.com/Azure/service-fabric-issues/issues/1095 [2]: https://blogs.msdn.microsoft.com/azureservicefabric/2018/05/22/new-service-fabric-client-library-for-net/ https://blogs.msdn.microsoft.com/azureservicefabric/2018/05/... [3]: https://github.com/Azure/service-fabric-issues/issues/ https://github.com/Azure/service-fabric-issues/issues/

qrli 8y ago

I have always avoided its VS project extension. If you do only `guest executable`, it is super intuitive and you can simply create any kind of exe with any language/stack. The package can be created by a few lines of PowerShell scripts, which is much simpler and more stable than its VS extension. Of course, the stateful service feature is lost. But k8s does not have that feature either. Till now, I see its `guest executable` solution a good balance.

algorithmmonkey 8y ago
> Of course, the stateful service feature is lost. But k8s does not have that feature either. Persistent Volume Claims go a long way toward the stateful service "feature". To go another step further on stateful services, SF's stateful services are only supported in a couple languages. Where mounting a volume in K8s which will follow your container is pretty darn accessible to any language.