service-fabric
service-fabric copied to clipboard
microsoft
AZ-203 Azure Service Fabric left out
I am a Service Fabric fan and I am working on preparing for https://docs.microsoft.com/en-us/learn/certifications/exams/az-203.
I am very surprised to see that ASF is not in the exam syllabus. There is AKS and containers and stuff but not ASF. So, what is the idea behind that? Will Microsoft be dropping support to ASF and moving to Docker, Kubernetes? I am also learning ASF, so please let me know whether ASF will be sunset.
I'm a consumer of Service Fabric, and one thing I've noticed is that Service Fabric has support for Stateful Services, but AKS does not. Until that feature parity is there, I would be surprised if Azure made the complete transition to AKS over Service Fabric. There are a lot of major Azure products running off of Service Fabric that would need to be ported over. Service Fabric has the maturity at this point, even if its not the current 'cool kid' on the block. Just my 2 cents, but it would be great to hear from a Microsoft resource on this one 😄
The roadmap concerning all of the products in this sphere (AKS, ASF, ASF mesh) and the new programming model/platform/... released (dapr) is not really clear. I was hoping ignite would show a path but it did not...
It's part of AZ-400 though. There we some questions about how Service Fabric fits in CI/CD.
@artisticcheese Thanks for the mention. Glad its part of CI/CD. Me being a developer, am interested to know more on the development front. Would appreciate if anyone from Microsoft can comment.
@alexv-be
dapr
https://cloudblogs.microsoft.com/opensource/2019/10/16/announcing-dapr-open-source-project-build-microservice-applications/
says
Although Dapr borrowed the Actor Framework and Stateful features from Service Fabric, There are a couple of major differences. a) Stateful services: Your code + data wont’ live together on dapr. You would need an additional I/O hop to access cosmos or redis [or your own state provider] to get to the data. In service fabric, once you hit a partition the data lives right there on that node. You will get much lower latency for reliable collection reads with Service Fabric. b) Service fabric runs classic .net and .net core. Dapr is only for .net core projects. This is a big deal for users who have vast assets on classic .net c) With external state provider, partitioning becomes a little murky on dapr. Service fabric gives you range and named partitions with replicas. I am not clear how dapr handles replicas or it delegates that to kubernetes or the underlying orchestrator. d) Service Fabric roadmap: https://github.com/Microsoft/service-fabric#service-fabric-release-schedule. so, to answer your question, Service Fabric is here to stay.
Thanks for positive feedback on Service Fabric. We would like to learn more about your Service Fabric workloads. Please share your contact information.
@athinanthny Hi,
I am learning ASF as well as preparing for Azure Certs. I work in non-ASF .NET based apps in my normal office hours, but have built multi-tenant saas apps as my pet projects, mostly monolithic.
Next on list, I am planning to build a multi-utility mobile app to which microservices are more apt in the back end. Hence I shortlisted ASF for it. The workload I am planning to use is https://docs.microsoft.com/en-us/archive/blogs/maheshkshirsagar/common-workloads-on-azure-service-fabric "Multi-tenant applications"
@athinanthny here is example and I believe it is not unique. We are going to migrate our enterprise product from legacy WCF Windows service-hosted monolith to some distributed cloud-friendly model. Classics. Among requirements there are: • ability to host app as on the cloud as on-premises; • both .Net Framework and .Net Core support (at least for the transition from .Net Framework period); • dynamic scalability, good balance between performance and resiliency; • state and health monitor; • rich programming model; • easy local deployment for dev/QA needs; • easy staged migration opportunity. To reduce the complexity, we are not interested neither in cross-platform nor in multi-lang/frameworks support. Just Windows and .Net.
From all those perspectives SF looks like a perfect match we would love to go with. All the POCs we've done so far give very promising results. But... Microsoft's attitude towards its own platform raises a lot of concerns as to SF future also mentioned in this thread. With a quite restrained updates on SF over the past year, it is hard to miss that huge effort Microsoft puts on propagation of Kubernetes and Dapr. The last thing we want is to endeavor to migrate from obsolete technology stack just to end up with another discarded platform. And there are no reliable statements on that, only contradictory guesses and gossips from various people. Even after requesting proactive hours for SF as a part of our Microsoft Premier Support subscription, Microsoft guys are trying to discourage us from going with SF because they have very little clues what's the hell SF is and what is its road map as a platform.
It would be extremely frustrating if after all we have to switch to Dapr, Kubernetes and all the zoo of their various come-alongs just because of lack of confidence in SF future.
Why are you not considering running just Windows containers inside Kubernetes instead of SF?
We did. It is a nightmare to run Kubernetes and containers in a highly-regulated corporate environment.
I imagine SF running in the same environment shall not be much different
As above, all SF proof of concepts work just fine. With SF reliable services I do not need to deal with all those local Hyper-V restrictions and other jazz.
I just don't want to turn this thread into debates around Kubernetes. My original point was about uncertainty about SF as a platform despite all its benefits.
@Tavriets We would like to have detailed follow-up to better guide you on next steps. Are you available to do a phone chat for 30mins next week (Tue-Friday). If yes, please share your contact info
@athinanthny, more than happy to have a call. Could you please contact me at my private address tavriets at gmail.com to arrange time?
@Tavriets those are a lot of the same reasons my company is moving to Service Fabric. Sadly we live in a culture of "sort by stars descending on GitHub" and I believe it causes more fear than is necessary.
We have a team of 5 people managing around 20-30 micro-services (full CI/CD pipelines). Even the process of standing up a new Service Fabric cluster is automated. We are an on-premise focused shop with the long term goals of having a parallel cloud offering. I can't imagine this kind of autonomy with such a small team using some of the other technologies that are available. Pick the right tool for the job, right?
@athinanthny what would be the best way to send you contact information?
@artisticcheese the SDK that Service Fabric provides for RPC between services and reliable distributed state persistence don't have an equivalent in K8's, at least not out of the box.
@athinanthny
If I need to migrate my Azure Cloud Services, I was hoping that ASF would be the best fit and I have started working on the same. But after seeing @Tavriets comment that "Microsoft guys are trying to discourage us from going with SF because they have very little clues what's the hell SF is and what is its road map as a platform." I am now really afraid.
Microsoft needs to take a strong stand and provide a long term support to ASF.
@JustinKaffenberger @Tavriets @srivathsanvlb Please reach us at [email protected] as early as you can and mention this git issue for references. We would like to talk to you all this week. We want to understand your usecase, hear your concerns, learn about your workloads and provide best guidance possible.
@srivathsanvlb to be fair I'd love to see @Tavriets get knowledgeable support for AKS and do a comparison. My suspicion is that with enough complexity any technology stack can become cumbersome for support to deal with, and simply migrating an existing architecture to AKS doesn't make the complexity go away.
As far as I know, Windows Containers on Service Fabric is currently the only production ready way to run Windows Containers on Azure, as it is still in preview for AKS. We don't current run containers on Service Fabric, just processes, but this is an important note if Windows Containers are important for you.
Windows containers are officially supported from vendors are on Docker swarm, Service Fabric and ACI. The problem with Service Fabric support is that despite today is February 18, 2020 they still don't support Windows 2019 as base OS when you deploy as PaaS in Azure. So it's not better then really any other alternatives. Service Fabric had such a nice headstart as you mentioned as far as running supported Windows containers but it's a joke now as far as Windows containers. How on Earth they still don't support Windows 2019 as host OS? Even Kube now have it in preview. For me personally SF is dead as far container orchestrator
@Tavriets @JustinKaffenberger we encountered email issue and will resolve it in 24hrs. Please reach us after 24hrs. Sorry for the incovenience.
@artisticcheese it appears that their docs are the issue. It looks like support for Windows Server 2019 was added in April of 2019: 6.4 Refresh Release
Yes but I don't beleive that version made it to Azure itself. Here is a list of supported OS versions if you create it from portal. Windows 2019 is missing and hence will not be able to run Windows 2019 containers as result.
@artisticcheese interesting, I will have to do more research on this new(ish) concept of the semi-annual channel. It seems to be something Microsoft is pushing for micro-service platforms. From this page in particular:
Containerized applications, container hosts, and application scenarios benefiting from faster innovation
but from what I can tell 1909 is the latest.
It is supported in standalone cluster but just not in Azure. ACI (Azure Container Instances) are actually running on top of Service Fabric (to some people surprise since they expected it to be running on Kubernetes) and that one have support for Windows 2019 in preview (https://docs.microsoft.com/en-us/azure/container-instances/container-instances-region-availability#availability---windows-server-2019-ltsc-1809-deployments-preview). So basically Azure Service Fabric is no better and and in reality worse in supporting Windows containers on Azure then Kubernetes.
I sent an email to the email address specified above and I would like share the response I received.
There is not a plan to drop support for ASF. We discuss our roadmap during events like our most recent Community Q&A (yesterday: https://m.youtube.com/watch?v=RcrYDPn9R4A) and are working to do a better job communicating current work items and progress.
In the meantime we have started to incorporate information into our release notes.
https://github.com/Azure/service-fabric/blob/master/release_notes/Service_Fabric_ReleaseNotes_70.md
In regard to the issue, we believe that this was an accident and that SF is present in higher level trainings but are following up on the issue.