I am developing a mobile application that makes extensive and continuous use of SignalR to communicate to a SignalR service.
I have previously assumed that I would use a Web Role to host the service, and then add more Web Roles backed by a backplane of Service Bus or Redis as and when the service needs to scale out. Using a Web Role would also allow me to significantly scale up if I wanted to avoid possible latency issues with the backplane.
However when I compare the pricing of the Web Role to Azure Mobile Services it appears that the Mobile Services may be cheaper.
So can Mobile Services be used instead?
And if so what are the pros and cons of doing so?
We are close to rolling out an update to Azure Mobile Services .NET backend which comes with some neat integration with SignalR built in. I'll be posting a blog on it on http://blogs.msdn.com/b/azuremobile/ (and of course on twitter #frystyk) when it's there and how to use it.
Henrik
Related
Why should I use Azure App Service and not just implement a common .NET RESTful Web API backend?
What's the explicit benefit of this service compared to a common .NET RESTful Web API backend hosted on Azure?
An Azure App Service is a place to host your web application or API. Normally when you have a .NET web API you host it behind IIS or something on a virtual machine.
Azure helps you with these common scenarios wit Platform as a Service (PaaS). An App Service completely abstracts the operating system and the way you host your web application.
App Service can host web apps both on Windows and Linux. You can use all kinds of frameworks such as PHP, .NET or Java. You can even host containers without worrying about the host.
A good sample to start with hosting your .NET Web App on Azure App Services can be found here: Quickstart: Create an ASP.NET Core web app in Azure
Yes, there is a huge difference between Azure App Service and .Net REST WebAPI backend on Azure.
Hosting on Azure can be done using two ways
Create your own VM, then install IIS and do all the required stuff
Use AppService Plan
AppService Plan allows you to leverage the powerful functionality of Azure. Here a separate VM is not assigned to you. Azure App service can scale automatically depending upon the Scaling rule which is not present in restful API hosted on Azure VM.
My question blatantly was a stupid Newbie question, and as such, I'm afraid it is non-sense, which I now know by the answers you've given.
I'm currently reading the book "Azure and Xamarin Forms" to learn Xamarin and Azure. Apparently it's outdated. It suggests to "create a Mobile App on Azure". From the book that Mobile App is just a plain App Service running a RESTful Web API with EF, but utilizing completely different namespaces to do so.
My question targeted towards these other namespaces. I didn't see a reason for them.
Apparently, Microsoft noticed the same. There is no "Mobile App" available in the Azure Marketplace anymore.
Azure App Service is a PaaS solution from Microsoft hosted on Azure. You can think of Azure App Service as some sort of "Micrsoft Heroku", because they work on a similar fashion. For many REST Projects, it can save you hours, if not DAYS of development. It has automatic TLS like heroku, but it is hosted on Azure instead of AWS and it can integrate very well with your existing Azure resources. One common pattern is to host the REST API on App Service and use a database service from Azure such as Azure SQL or Cosmos DB (which is a NoSQL service that, from the point of view of your app, it operates as MongoDB, but can be configured to behave as other DBMS).
I have an azure mobile service that is running on top of SQLAzure DB. The Database is geo-replicated. I am looking to setup a failover for mobile service in case if the primary endpoint goes down. I have looked into traffic manager but it does not support mobile service endpoints also setting up another mobile service that talks to the replicated DB not possible as the replicated copy is read-only.
What are the possibilities of setting up a failover for mobile services endpoints.
There are several mechanisms for hosting mobile APIs on Azure - Azure Mobile Services is tied to a single region, so you can't fail that over. Azure Mobile Apps is the next generation of Azure Mobile Services and is built on top of Azure App Service Web Apps - it's an extension of the work there. As a result, you can leverage all the cool features of Azure App Service for your mobile service. If you haven't taken a look yet, then take a look at migrating your service to Azure App Service Web Apps.
Once there, Traffic Manager is definitely what you want. You can read about the process of using Traffic Manager with an Azure web app here: http://blogs.msdn.com/b/benjaminperkins/archive/2014/06/02/using-traffic-manager-with-microsoft-azure-web-site.aspx
I am working on hosting a SaaS solution on Azure that is using elastic sql auzre for multi-tenant scenario. The client will communicate with the back-end via Azure Mobile Services. Mobile services provides auto scale capabilities on standard tier. My question is that will this auto-scale be sufficient for a product app with thousands of API calls? or should I consider some other setup such as multiple mobile services in different locations? CDN's etc.
Yes, absolutely. Azure App Service Mobile Apps can scale up to 10,000 API requests per second. Beyond that, you need to think more closely about architecture, which is a bigger question.
I have created an Azure Web App today and it has a Mobile section in the Settings which contains Push notification, Mobile Authentication, etc. You can even download the source code for a mobile client app. I know that this used to be part of Mobile App (Mobile Service). I have created an Azure Mobile App to compare with Web App and they look the same in terms of Settings and Tools. Even the Icon is the same.
My question is what is what is the difference between Azure Web App and Azure Mobile App?
Like you, I couldn't get my head around the difference between the different types of App Service apps (Web Apps / Mobile Apps / API Apps). Judging by the fact that no one has really answered your question, it looks like we weren't the only ones.
It made no sense to me that Web Apps, Mobile Apps and API apps were distinct things: surely the whole point is that you should be able to expose an API that serves your web site, your mobile apps, any other kind of client, making use of whichever features you need for your use case?
And, lo and behold, buried deep in the Azure docs:
The only difference between the three app types (API, web, mobile) is the name and icon used for them in the Azure portal.
Yep: they're exactly the same.
In old days of Azure, they had 2 offerings - Azure Websites and Azure Mobile services. Some time ago, both of them got rolled into something called Azure App Service which also included two more kinds of apps - API Apps and Logic Apps.
To answer your question specifically, Azure Web App is new name for Azure Websites that you can use to build websites in multiple languages where as Azure Mobile App is the new name for Azure Mobile Service that provides backend infrastructure for mobile applications (or in other words, Azure Mobile App is Mobile Backend-as-a-Service [MBaaS] offering from Azure).
Mobile Service is the "classic" version and is only available in the classic portal. Mobile Apps is part of App Service is only available in the preview portal.
App Service includes Web Apps, Mobile Apps, API Apps and Logic Apps is deployed as one unit. Using the classic way, you would have to create and pay let's say for a Web App and a Mobile Service so you can save money using the App Service. You also get a larger selection of VMs.
Not all Mobile Services features have been migrated yet to Mobile Apps. If you use a Node.js backend, there's no nice UI built-in in the new portal to manage your JS code.
Note that Microsoft has not announced that it will deprecate Mobile Services.
I have found some subtle, but key, differences. Assuming a C# backend, the Mobile App Service controllers will inherit from TableController - which provides out-of-the-box CRUD operations on a table, compared to the Web Api 2 style ApiController (which you can still use in a Mobile App Service). Any less confused now?
Sorry for the late reply. They all are really the same thing. If you look in Azure Resource Explorer (available in the application menu of your app or resources.azure.com) you will see the indication of how we display a different icon for it - "kind": "mobileapp", for Mobile Apps for example. We leverage the different kinds to provide different quick-starts. You can certainly create an Azure Web App and load Azure Web App code to it to get the Mobile Functionality.
I have searched a lot on this topic but didnt get any satifactory answer.
In Windows Azure how can we consume an external (third party) Web Service from the worker roles? Is it as simple as using a web reference in the solution or is it necessary to use Azure Service Bus?
It's as simple as calling the webservice using whatever method you need (REST, SOAP, etc.). For .NET developers using .asmx or WCF SOAP services, just generate the proxy like you normally would. In this model, there is no difference between what you do onpremises when the cloud is the client.
You would look at using the ServiceBus when you are hosting your own services (as opposed to consuming them), typically behind firewalls onpremises, and you want to give secure access to them or integrate them into cloud scenarios. There are other scenarios and capabilities of course, but that is a main one. If you simply want to consume another web service, the ServiceBus has nothing to do with that.
As long as the 3rd-party web service endpoint is reachable, use it the same way you'd use it from an on-premises server. If you need to connect to a service endpoint behind someone's firewall, then you'd want to consider AppFabric Service Bus.
Just remember that you'll be paying for bandwidth out of the data center (unless the 3rd-party web service is Windows Azure homed, and in the same data center).