Azure App Service vs Azure Service Fabric [closed]
Asked Answered
A

5

54

Can anyone direct me to something that will explain when I should create an Azure Service Fabric application vs an Azure App Service application? I have an application I want to build but can not determine whether I should build it using the Azure Service Fabric or the Azure App Service.

Action answered 30/6, 2015 at 14:18 Comment(3)
I don't think there's a definitive guide out there - it depends on what you're trying to build and what kind of team you have. Maybe you can share some of that information?Neuroma
It's an custom enterprise project management application that could expand into a content management system and more. It can easily be built using standard API and Web apps but I am not sure what I would be giving up. I like the scalability of the Service Fabric, both from a performance as well as development standpoint. However, I do not know what I would be giving up if I take this approach over the App Service approach. What I was hoping for was something that would outline the pros and cons of each approach. How do you decide between the two?Action
You may find this article comparing Azure App Service, Virtual Machines, Service Fabric, and Cloud Services useful - learn.microsoft.com/en-us/azure/app-service-web/…Analog
E
34

Microsoft has created the document with a comparison for Azure App Service, Virtual Machines, Service Fabric, and Cloud Services. Also, you might find helpful this decision tree.

Effeminacy answered 14/5, 2017 at 15:26 Comment(1)
I wonder how drastic price differences are??? Take this example: I deploy a single instance Hello World webpage to App Service. I then compare the price doing the same to Service Fabric.Mien
N
43

Unfortunately there isn't any official guidance about when to use what. They're two separate platforms, following different development paradigms.

The App Service will give you functionality that Service Fabric doesn't provide out of the box. Stuff like auto-scale, authentication, rate limiting, integration with SaaS applications, etc. Some or all these things may come to Service Fabric gradually, but I'd say that, at the minute, they're targeted at different audiences - a less experienced team might find it easier to work with the App Service.

Service Fabric on the other hand makes composition of parts easier. For example, in the "traditional" approach, if you had an API that speaks to a data store and a cache to avoid hammering the data store, you'd have to handle the various fault tolerance scenarios. With Service Fabric your cache can sit within the API process in a reliable collection and you won't have to deal with having an external cache component. The data is co-located with the service (faster to retrieve/edit!) and is reliable as it's distributed across all the nodes the service is deployed into. Similar thing with queues. If you think of a workflow type system, where there is an API, a job service, and a queue that sits between them and allows them to communicate, you'd have to manage 3 different components and the communication between them. With Service Fabric the queue comes into the application. And that's just half of it :) you also get the power of using the actor model for distributed computation without the usual concurrency headaches. Finally, with Service Fabric you get the benefit of having a more complete development environment on your local box - you don't have to deal with creating queues, etc. on an Azure dev account or anything like that.

Also worth noting that there's nothing stopping you from using both paradigms - imagine two apps with at least one of them being a service fabric app, that expose APIs and a logic app that sits on top of those.

Your decision should be based on what you're trying to build, in how much time, when you want to release (Service Fabric is currently only in private preview so it'll be a while until they get to GA) and what kind of team you have. I imagine that with the App Service it'll be easy to hit the ground running even if you don't have a massively experienced team, but Service Fabric will give you more power, flexibility and control.

Neuroma answered 1/7, 2015 at 10:1 Comment(4)
Thank you Charisk, this definitely helps. I think the hybrid model is attractive. I would like to leverage the simplicity and added features of an app service for my web and API apps but I would like to build out the back end of the system using service fabric. I will dig into understanding how to do this more. Hopefully, there is a way to get the best of both worlds. :)Action
This should be the preferred answer. Funny how in a lot of situations the second answer is usually better :-)Kedah
@Kedah Note that this answer is 2 years older than the accepted one. In that time Microsoft published what is, effectively, an "official" answer to this question. While I don't love answers that are just a link, the accepted one probably is the most current and relevant. Kudos to the OP for coming back and accepting it.Burgener
Sounds useful answerUnprejudiced
E
34

Microsoft has created the document with a comparison for Azure App Service, Virtual Machines, Service Fabric, and Cloud Services. Also, you might find helpful this decision tree.

Effeminacy answered 14/5, 2017 at 15:26 Comment(1)
I wonder how drastic price differences are??? Take this example: I deploy a single instance Hello World webpage to App Service. I then compare the price doing the same to Service Fabric.Mien
B
4

App service is a more managed service , SF is more you manage your own and you can run on your own premises as well. SF has better support for non MS stack dev eg native apps etc.

As that document states "Service Fabric is a good choice if you’re creating a new app or re-writing an existing app to use a microservice architecture. "

If your hosting a few apps you should not be looking at SF , On the other hand if your deploying more than 10 services than it becomes a better solution.

Also note SF has a data storage mechanism that is included with the services . It is good at 3 things 1) Massive clusters of data 2) Simple data, often in Micros services DBs become a heavy burden since each service should have its own data and things like SQL are bit overkill when you only have 1-3 tables. 3) State storage for the Actor programming model.

I think SF and Web apps will slice the "Cloud Service" user base in the future.

Balaklava answered 27/5, 2017 at 13:20 Comment(0)
Y
2

If (App may required to scale up in future || want to build App with micro service architecture) go for Azure Service Fabric

else Azure App Service is ok

Yahwistic answered 21/1, 2019 at 13:29 Comment(0)
L
0

Use Service Fabric when you need more control over, or direct access to, the underlying infrastructure.

Use App Service when you need a fully managed hosting platform for your web apps.

-as per documentation

Lyckman answered 29/11, 2018 at 9:8 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.