Last night I attended a meetup at Microsoft‘s NYC headquarters entitled “How to Rock Windows Azure Mobile Services.” The presenter was Jim Priestley, a Technical Solution Specialist at Microsoft. Windows Azure is Microsoft’s cloud platform that competes with Amazon Web Services and other similar offerings. At the time it was launched in 2011 Azure was unique because it was the first to offer a “platform as a service” (PAAS) model, which allowed developers to deploy and manage their applications without having to configure individual virtual machines. Since then Amazon and others have responded with similar offerings.
Today Azure is a large, rapidly evolving, platform-agnostic service with many different and sometimes confusing offerings and tools: Azure Web Sites, SQL Azure, Azure Cloud Services, Azure Traffic Manager, Azure Caching, Azure Service Bus, etc. Azure Mobile Services is the name for Microsoft’s platform for rapid developing backend services for mobile devices. It is a scalable multitenant hosted application that allows developers to easily 1) store data in the cloud, 2) authenticate users using federated single sign on (SSO), 3) send push notifications to various mobile platforms.
Storing data in the cloud using Mobile Services is currently limited to SQL Azure, a cloud-based version of SQL Server, but this will likely change in the future given the growing popularity of NoSQL databases like MongoDB. Azure Mobile Services automatically creates a dynamic JSON REST API based on your database schema, allowing your mobile apps (or any other REST clients) to perform CRUD (create, retrieve, update, delete) operations over HTTP easily using an open-source SDK that is available for all major mobile platforms. To make it even easier, Microsoft allows you to download pre-built solution files for Windows Store, Windows Phone 8, iOS, Android, and HTML5 that are already configured with your service URL and API key. User authentication is accomplished by using federated single-sign-on using Facebook, Twitter, Windows Live, or Google, with Active Directory support in the works. Push notifications are performed via Microsoft’s API, which queues and throttles requests to prevent overloading those Apple’s or Google’s backends.
Currently a Mobile Service can only run on one of Azure’s 8 global datacenters (4 in the US, 2 in Europe, 2 in Asia, and 2 in China are coming). Each service instance can scale up to 10 virtual machines. That means that for very large applications, multiple instances must be deployed (in the same datacenter or another), and then load-balanced and synchronized behind the scenes using other Azure services. Alternatively, developers can opt not to use Mobile Services but instead go with “Cloud Services” which are compiled .NET applications that have many more features and can be deployed and scaled much more precisely.
In the end, Jim calls Mobile Services is an “enablement platform” to dynamically spin up backend services for mobile apps. It provides ease of use but clearly sacrifices certain features. More demanding applications should use Azure Cloud Services (which is still PAAS), and for the most intense projects, you can always manage your own virtual machines for 100% customizability. Jim does add that Mobile Services is a very visible project a Microsoft and they will likely be adding many more features in the future.
Mobile Services is technically still in Preview mode. It will go general availability (GA) this summer with an Enterprise-grade service level agreement (SLA). Future features include: other server-side scripting languages (like C#), integrated source control management of server-side scripts, and easier broadcast push notifications. Azure is on a 6-month planning schedule with weekly production deployments, so expect many new features in the future. Many new features will be announced at the Microsoft BUILD Developer Conference this June 26-28 in San Francisco.
I’ve actually started using Mobile Services as the backend for push notifications in my Brella app. I’ve hit some limitations given the complexity of the implementation and had to move some components to Cloud Services instead. When I’m done I’ll write about my experiences here.