search

microsoft / service-fabric

Service Fabric is a distributed systems platform for packaging, deploying, and managing stateless and stateful distributed applications and containers at large scale.
https://docs.microsoft.com/en-us/azure/service-fabric/
MIT License
3.02k stars 399 forks source link

AZ-203 Azure Service Fabric left out #433

Open srivathsanvlb opened 4 years ago

srivathsanvlb commented 4 years ago

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.

JustinKaffenberger commented 4 years ago

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 😄

strat-alex commented 4 years ago

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...

csesek commented 4 years ago

Yes, we need this info

erYasar commented 4 years ago

Valid observations, need a clear information on road map towards ASF.

artisticcheese commented 4 years ago

It's part of AZ-400 though. There we some questions about how Service Fabric fits in CI/CD.

srivathsanvlb commented 4 years ago

@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.

srivathsanvlb commented 4 years ago

@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.

athinanthny commented 4 years ago

Thanks for positive feedback on Service Fabric. We would like to learn more about your Service Fabric workloads. Please share your contact information.

srivathsanvlb commented 4 years ago

@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"

Tavriets commented 4 years ago

@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.

artisticcheese commented 4 years ago

Why are you not considering running just Windows containers inside Kubernetes instead of SF?

Tavriets commented 4 years ago

We did. It is a nightmare to run Kubernetes and containers in a highly-regulated corporate environment.

artisticcheese commented 4 years ago

I imagine SF running in the same environment shall not be much different

Tavriets commented 4 years ago

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.

athinanthny commented 4 years ago

@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

Tavriets commented 4 years ago

@athinanthny, more than happy to have a call. Could you please contact me at my private address tavriets at gmail.com to arrange time?

JustinKaffenberger commented 4 years ago

@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?

JustinKaffenberger commented 4 years ago

@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.

srivathsanvlb commented 4 years ago

@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.

athinanthny commented 4 years ago

@JustinKaffenberger @Tavriets @srivathsanvlb Please reach us at app-plat-sl@microsoft.com 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.

Tavriets commented 4 years ago

@athinanthny app-plat-sl@microsoft.com rejects incoming messages. At least from my address.

JustinKaffenberger commented 4 years ago

@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.

JustinKaffenberger commented 4 years ago

@Tavriets I have the same issue with the email address.

artisticcheese commented 4 years ago

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

athinanthny commented 4 years ago

@Tavriets @JustinKaffenberger we encountered email issue and will resolve it in 24hrs. Please reach us after 24hrs. Sorry for the incovenience.

JustinKaffenberger commented 4 years ago

@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

artisticcheese commented 4 years ago

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. image

JustinKaffenberger commented 4 years ago

@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.

artisticcheese commented 4 years ago

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.

srivathsanvlb commented 4 years ago

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.

tedvanderveen commented 4 years ago

There has been a lot of FUD spread around the community around Service Fabric. What most people do not realize, is that Azure actually runs on SF. Massively scalable multi-tenant stuff like CosmosDB, runs on SF.

https://dev.to/aloneguid/is-azure-service-fabric-still-relevant-in-2020-4j87

SF is not going away. Many enterprises run their mission critical workloads on SF. It's just not so very visible compared to the k8s screaming community herds.

MylesRip commented 4 years ago

I'm a bit concerned that the November 2019 release of the eShopOnContainers sample application, which showcases how to build .NET applications using microservices and containers, has added a deployment option for AKS, while "retiring" Service Fabric as a deployment scenario. See the release notes here. I like the benefits of SF, but I'm hearing mixed messages.

strat-alex commented 4 years ago

I personally always had a very consistent answer from MS about SF: it's not going anywhere. I've had this response using different channels, including this one. And at this point, I can only trust this is the case, although some of the evidence clearly points in another direction, the released roadmap was a great confirmation.

What I do worry about, is the fact that MS seems to be pushing K8S more than the in-house developed alternative (SF), the technology that actually solves a ton of service oriented architecture problems. This inevitably leads to a "see, even MS pushes kube over SF"-conversation with customers when proposing SF's value. For the Microsoft focused enterprise SF makes a lot of sense. There's something to be said about some good old-fashioned competition to drive innovation.

darraghjones commented 4 years ago

Now it seems even Microsoft is starting to migrate away from Service Fabric:

https://www.theregister.com/2020/06/17/microsoft_plans_to_move_teams/

dazinator commented 3 years ago

Any updates?

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

Why the preferential treatment - can't you post an update somewhere for all to see? So confused about the roadmap for SF, SF MESH and DAPR. DAPR doesn't seem to support SF Mesh. SF Mesh has been in preview forever with no real news on when or if it will ever reach GA.

JohnNilsson commented 3 years ago

Has there been any more communication about teams abandoning Service Fabric? An community Q/A session I've missed?

Would be very interested to hear the details of how SF failed teams enough to motivate such an investment, and what the response from sf team is. And of course, any details that could shed some light on the future.

tedvanderveen commented 3 years ago

Just dropping this here: https://twitter.com/3tornados/status/1243393599309414400 During the giant upsurge in usage of Team in March (Covid outbreak), it was actually SF that saved the day. I keep reading quite a lot of rumors regarding future of SF, but until there is an official statement regarding abandoning SF from MS, I shall just regards those rumors as FUD.

captainjono commented 2 years ago

Just dropping this here: https://twitter.com/3tornados/status/1243393599309414400 During the giant upsurge in usage of Team in March (Covid outbreak), it was actually SF that saved the day. I keep reading quite a lot of rumors regarding future of SF, but until there is an official statement regarding abandoning SF from MS, I shall just regards those rumors as FUD.

We use SF extensively (largest SF customer in region at one stage), but strategically we can now reimplement services using serverless/aks and get as good performance without the complexities and overheads of SF (including specialised resources to maintain systems). Our problems are not if SF is capable or not, its the limitations around its scaling and state replication that make our solutions costly to operate.

On every support call with MS on SF, the SF team shrugs there shoulders "orly? we don't pay, so wouldn't know" and that's that. We are not seeing the focus on the customer, because in this case, we are just a small drop in the pool - Azure gets what it needs and there is little leftover for others.

To me, this is the real story at play when people talk about SF being pulled back from the public and kept internally. Its costing modal wasn't designed to be a competitive SaaS product, its deployment flexibility is limited by its Architecture (its designed to meet the needs of Azure, remmeber! they don't micromanage costs, they just spin up clusters and goto town!...) So while your solution may continue to be supported, you will pay for the privilege of using "the tech that powers Azure (tm)".