Advantages of hosting a mobile app back-end in Azure Mobile Services over Azure Websites

Question

I have a WebAPI back-end for a mobile, and want to host it in Azure.
I am having a hard time figuring out the real differences between AMS and Websites.

All the articles I read about the subject talks about changes and benefits in general, and I want to understand specifically which new features AMS provides, and the benefits of hosting in AMS.

Authentication

---

In AMS I see the "IDENTITY" tab in azure portal. From what I understand, those 3rd party configs allow me to authenticate my users easily with google,FB etc. But this is just making the process more convenient and configurable via UI. In Websites, I can achieve the same functionality pretty easily using code from ASPNet.Identity and OWIN libraris.

Push Notifications

---

Again looking at AMS in the "PUSH" tab, I can see two mechanisms. The Notification Hub and 3rd party section.

The Notification Hub is nothing special to AMS, and I can get the exact same functionality when hosting in Websites.

The 3rd party section allows me to configure credentials to push services from Apple and Google (APNS,GCM...) and together with libraries in AMS namespace I can easily write code to communicate with those services.

But When hosting in Websites, in my back-end I can use open source libraries. For example, Moon-APNS to talk to APNS.

Scale

As far as I understand, both Websites and AMS allows the same scale functionality (One calls it Units and the other Instances).

---

Are there any big differences I missed?
Are any of the claims I made are incorrect? It would be great if anyone could shed some light on the matter, specifically addressing all the 3 issues (Auth,Push,Scale).

Answer 1

That's a question I often get when I present Mobile Services at user group events.

For a .NET developer, there's nothing really special about Mobile Services since everything it offers, you can do it with a Website.

Mobile Services really shines for non .NET developers since you can have a complete mobile backend by writing scripts running on Node and Mobile Services abstract all the database and REST complexity.

I will likely get downvoted since I'll express a personal opinion but anyways: I see no obvious reasons for using Mobile Services if you're coding a .NET backend.

Answer 2

I think you are exactly the target customer for Azure Mobile Apps. You will get all of the power of having your own Azure Website (now rebranded as Azure Web App), with the additional convenience and client libraries of Mobile Services.

One feature of the client library that you may not have noticed is the cross-platform offline data sync capability. That's usually hard to build on your own, and we have an implementation that's conceptually consistent across all client platforms. (Plus, if you use Xamarin, you can share code between your client implementations.)

To be clear: Azure Mobile Services is NOT deprecated, and will not be until long after GA (general availability) of Azure Mobile Apps. Azure Mobile Apps is currently in preview.

Answer 3

The other big benefit of Mobile Services that you haven't mentioned is the client libraries for Android, iOS, Xamarin, and Cordova. If you already have a REST client library in your app and don't need to worry about multiple client platforms, then Azure Web Sites sound like a good way for you to go.

Answer 4

AMS by itself is built on top of Azure Websites. So you can actually implement everything in an Azure website that is available in AMS.

However, the good thing about AMS is that it allows you to quickly build the backend for a mobile app with CRUD operations, authentication/authorization and also provides client side libraries for different type of clients e.g., HTML, C#, etc. so we don't have to manually make the HTTP calls.

If you have need to implement the above functionality in Web API, it is quite an effort. Isn't it?