Azure App Service vs Azure Service Fabric
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.
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
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.
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.