The other day I was chatting with my colleague Nick Pinheiro about possible architectures of mobile solutions with Azure. As you may or may not know Windows Azure is the Microsoft Cloud. They provide a bevy of services from Website hosting to API creation, data storage, machine learning and much more. Nick and I are in the process of building separate mobile applications and we often spit-ball ideas about the architecture of our applications and how we handle certain scenarios as they come up with our applications. to set the basis of what we have been discussing, Nick’s application started off as a web application (actually, it’s a Facebook app in which Nick was honored as having one of the top Facebook apps on the planet!). He is now in the process of making his app a native mobile application. My application comes from the perspective of building a brand new Azure Mobile Services application. Both approaches have their own unique pros and cons. So this lead us to wonder what might be the pros and cons of using Windows Azure Mobile Services vs. building a mobile application using the individual (A la Carte) services offered by Windows Azure. So that is what we will be discussing in this post.
To make the comparison apples to apples I wanted to compare the features and the cost of building an application using both methods. In order to do this we have to get down to the basis of what Azure Mobile Services provides as these features/services provide the basis for the comparison. Azure Mobile Services can be though of the combo meal at your favorite fast-food joint. It comes with a bunch of services all wrapped up in a nice package for 1 low prices. It is also scalable with the touch of a button just like most of the other services in the Azure world. For the basis of this conversation we are going to compare the following features:
In comparison the A la Carte service which will allow the creation of a REST based API with a the application’s domain is the Azure Website. With the Azure website you have the flexibility to use whichever language suits you best. This service is providing you a website platform for which you can publish your web API services. Your data storage will need to be created/defined separately, however you will have the flexibility to choose the persistent data store you would like to use. Lastly, you will need to provide some custom security to protect your Web APIs from unauthorized access. All that said, there is a lot more work to get this architecture correct, however you have the ultimate in flexibility in regards to platform and scalability.
One of the many things our applications will need to do is perform some automated, long running process. This could be as simple as resizing images upon upload to screen scraping other websites on a scheduled basis. Azure Mobile Services provides the ability to create these long running process as scheduled jobs. The equivalent A la Carte service is Web Jobs and/or Azure Scheduler. The key difference here is again with Azure Mobile services you have easy access to your data store by leveraging the services component in Mobile Services. With the web jobs and/or the scheduler service you will have to make those connections manually, good new here is this is not hard and is documented well for the most part.
One of the main methods of keeping users engaged in todays applications is to provide some type of notification. In the mobile world this is done via Push Notifications. Windows Azure has created a world-class notification hub will allow you to provide this functionality to your applications quickly. In fact the A la Carte Notification Hub is what Mobile Services leverages inside the Mobile Platform service. The services and service levels here are the same, the only difference is the cost as the hubs are included as a part of mobile services. The draw back to mobile services here however is, if you application sends a lot of notifications you might have to scale up to the Standard package for notification services alone, this of course will cause you to incur more costs.
Offline Data Sync
The Azure Mobile SDK provides a basic level of Data Synchronization down to the clients. This will allow applications to asynchronously cache data down to the device, hence providing a more responsive application experience. This feature is only available however to the .NET backend and is restricted at the time of this writing to Tables only, hence if you use the API features of Mobile services this feature will be of no help to you.
On the A la Carte side of the house, you guessed it, you will have to write this yourself. The good new however, is you have the ability to build/design your own asynchronous model and define how the data should/will be cached to the devices.
Lastly, authentication! After all we need to know who is using our application, provide some level of customization to better engage users, or maybe we just want it for analytics. Whatever the case Azure Mobile services provides the ability to login using OAuth to the 4 major providers of Authentication Services (Google, Microsoft, Facebook, and Twitter). It also has hooks to allow authentication to Active Directory Services (yet another of the great services provided by Windows Azure). The ability to create your own user store however is missing and you will need to build your own if you want custom authentication. Chris Risner, provided a great post on doing this however.
As for an A la Carte service, there is no clear winner here. If you want to do Active Directory then you have the ability to leverage Azure Active Directory and use the DirSync solution to provide single-sign-on capabilities if connecting to an enterprise AD. Connecting to the other big services however will need to be built into your web API above or natively built into each of your client applications.
Pros of Azure Mobile Services
- Quickly create secure and manageable REST bases Web API service.
- Automatically have access to a DB backend.
- Easily scale to more instances as needed
- Easily connect to the major Authentication sources (Microsoft, Google, Facebook, Twitter, and Active Directory)
- Authentication to the big user stores is easy
Cons of Azure Mobile Services
- SQL database Schema is defined for you. Modifying the DB schema is possible however not straightforward.
- Limited to the platform capabilities.
- Custom Authentication is a challenge and must be built from scratch
Pros of Al a Carte
- Complete flexibility. You can scale each part of the application and scale each one as needed
- More readily adaptable by current applications. The brownfields scenario of an already existing back-end can move to the cloud and leverage the scalability and power of Azure.
Cons of Al a Carte
- Costly as you are not getting the benefit of the Mobile services platform as a service pricing.
- Harder to manage and scale as you will need to take the architecture of your application into consideration and have the ability to monitor each component separately.
- Authentication is all custom
|Feature||Mobile Services Basic||Mobile Services Standard||A la Carte Basic||A la Carte Standard|
|API/Web||1.5M API calls, built in security roles, offline sync||15M API calls||Unlimited Calls, however offline sync must be managed$56/mo + ($9/mo for SSL)||Unlimited Calls, however offline sync must be managed$74/mo + ($9/mo SSL)|
|Web Sockets||350 (only in .Net)||Unlimited (only in .Net)||350||Unlimited|
|Scheduler||50K jobs included||500K jobs included||$13.99 (50K included)||$139.99 (500K included)|
|Push Notifications||Basic Included 10M messages||Standard Included 10M messages||$10/mo 10M messages||$200/mo 10M messages|
|Offline Sync||Included in SDK||Included in SDK||Manual||Manual|
|SQL Server||Standard Rates||Standard Rates||Standard Rates||Standard Rates|
In summary, if you are creating a brand new application, or even a new set of interfaces for an old application then Mobile Services is most likely the way you will want to go. While you are restricted to the platform service it does provide integration of many features “for free”. However, if you have an already existing application (brownfield) scenario where maybe the authentication is custom, there is already a data schema built and users are already leveraging the application (typically this might be converting a web application to a native mobile device application, like Nick) then A la Carte might be the way to go. As always way your costs and benefits of the architecture before you make your decision.
Checkout Nick’s upcoming eBook Delivering Modern Apps as a Service with Azure
Follow me on Twitter @livehands