3 ms·

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 nat

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/
youdontknowtho 8y ago
On one of the teams QnA sessions they admitted as much about the UI tooling. I think that the guidance for a "real" app would be to use the command line tools. It's a fair critique though. It's not obvious how you would build a proper SF app that takes advantage of the platform. Hopefully that will change as it is open sourced. I built something on an early build of SF that was pretty simple and it was hard to get up to speed. It was more of a batch oriented thing that ran off of queue inputs, so I didn't have to deal with getting load balancing inbound traffic working or other stuff. Looking at SF recently it looks like they have made a lot of interesting changes like DNS service resolution. Something like Azure AD managed service instances would make bootstrapping secret management a lot easier. I would really like to see the ability to write PowerShell that plugged into the SDK and could take advantage of everything. The comparison to K8s is more like the "guest exe" project wrapper they had. If you aren't interested in the API's for plugging into their storage or other platform features you can just wrap an executable and specify some parameters about how to host it in configuration. This is one case where the VS tooling didn't do SF any favors. People think it's the only way to use the thing.

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/

youdontknowtho 8y ago

On one of the teams QnA sessions they admitted as much about the UI tooling. I think that the guidance for a "real" app would be to use the command line tools. It's a fair critique though. It's not obvious how you would build a proper SF app that takes advantage of the platform. Hopefully that will change as it is open sourced. I built something on an early build of SF that was pretty simple and it was hard to get up to speed. It was more of a batch oriented thing that ran off of queue inputs, so I didn't have to deal with getting load balancing inbound traffic working or other stuff. Looking at SF recently it looks like they have made a lot of interesting changes like DNS service resolution. Something like Azure AD managed service instances would make bootstrapping secret management a lot easier. I would really like to see the ability to write PowerShell that plugged into the SDK and could take advantage of everything. The comparison to K8s is more like the "guest exe" project wrapper they had. If you aren't interested in the API's for plugging into their storage or other platform features you can just wrap an executable and specify some parameters about how to host it in configuration. This is one case where the VS tooling didn't do SF any favors. People think it's the only way to use the thing.