Review: Microsoft Azure beats Amazon and Google for mobile development

In the last year I've reviewed six MBaaS (mobile back end as a service) platforms: FeedHenry, Kinvey, Parse, AnyPresence, Appcelerator, and Appery.io. I also briefly examined the MBaaS platforms associated with Pivotal CF and IBM Bluemix in my reviews of those PaaS (platform as a service) offerings. All of these MBaaS platforms run on some kind of public cloud, and some can be installed on-premise or in hybrid cloud configurations.

Not to be left out, the three major public cloud services have either developed or bought MBaaS platforms of their own. Amazon developed the Mobile SDK with multiple mobile-specific services, along with ways to tie mobile apps into its mainstream services such as DynamoDB and S3. Last October, Google acquired Firebase, which offers a secure, real-time, cloud-hosted, NoSQL database with a REST API as well as a login service. Microsoft Azure Mobile Services also includes non-Microsoft service components such as the Node.js Web API and MongoDB storage, as well as the .Net, Active Directory, and SQL Server cloud services that you'd expect.

Amazon Mobile SDK

The AWS Mobile SDK includes Cognito, Mobile Analytics, and SNS push notifications. Amazon Cognito helps you securely store, manage, and sync identities and data across multiple devices, platforms, and applications. You may also want to use DynamoDB, S3, and other Amazon services with your mobile app; you can use Cognito to manage those credentials as well. Apps built with Cognito work offline by syncing Cognito with local storage. 

Cognito user profile data is organized in data sets of up to 1MB of data in the form of key-value pairs. Read and write operations performed on a data set affect only the local store until the synchronize method is invoked. Amazon offers user game state as a use case for Cognito data sets. If you need to store and retrieve non-user-related data, then Amazon DynamoDB, S3, MongoDB (run in an Amazon EC2 instance, for example), or a relational database such as MySQL or PostgreSQL (both available as managed database services in Amazon RDS) might be better choices. Cognito could help by storing the per-user credentials for those data stores. 

Amazon currently has production Mobile SDKs for Android and iOS, as well as a developer preview for Unity. A Mobile SDK for Xamarin is available on AWS Labs. 

Amazon Mobile Analytics is a service that lets you collect and analyze your application usage data. In addition to viewing its own summary, you can set up automatic export of your usage data to Amazon S3 to work with other data analytics tools from Amazon Redshift or whatever you like. Amazon Mobile Analytics is designed to process and export your application event data within an hour.

Amazon SNS can push notifications to Apple, Google, Fire OS, and Windows devices, as well as Android devices in China (with Baidu Cloud Push).

I downloaded, installed, and tested the AWS Mobile and Cognito SDKs and samples for iOS and Android, as well as configured a Cognito service and Identity Pool on Amazon. All of that took longer than it should have, as I found the documentation and downloads scattered and confusing, although on re-reading I discovered that the docs are correct and (barely) complete enough to use. I made one mistake after another -- fortunately, none of them fatal. The process reminded me of assembling furniture from Ikea.

I was eventually able to build (Figure 1) and run the samples, then fill in my credentials in the right place (for iOS, that’s Constants.h) and run them without errors (Figure 2). I started working on this on a Thursday afternoon, spent half of Friday on it, took the weekend off, and finally got everything going Monday morning. It would take me less than two hours now that I’ve grokked how it works and purged all the mistakes from my system.

I was surprised to have to update my iOS and Android tools during this process, but realized that I had been using cloud-based mobile builders for the previous month or so. Make sure your tools are up to date before starting to work with the mobile SDKs if you’d like to avoid the interruption in your flow that updating them could cause. 

While the AWS Mobile SDK does what it sets out to do, developing with it is not for novices, JavaScript programmers, or the faint of heart. There are other AWS SDKs -- for Java, .Net, PHP, Node.js, and JavaScript for browsers. The Cognito Sync Manager SDK for JavaScript, currently in developer preview, combines with the AWS JavaScript SDK for the browser to provide a reasonable set of APIs for mobile Web and mobile hybrid applications, but it hasn’t (yet) been tailored to any JavaScript frameworks and it’s not the simplest JavaScript API in the world, as you can see in the blog post that discusses how to use it.

The AWS Mobile SDK might be a good choice for native app developers who already have a commitment to Amazon services. If you want an easy-to-learn and easy-to-use MBaaS, look elsewhere. 

Google Firebase

Google Firebase is a real-time, cloud-hosted, NoSQL database with a REST API optimized for low latency. Firebase also has a login service with several types of built-in authentication. Firebase lacks some features you'd expect in an enterprise-grade MBaaS, such as push notifications and back-end integrations with systems of record, but it supports location queries with its GeoFire library.

For security, Firebase requires SSL encryption with 2,048-bit certificates for all data transfer, offers granular access controls, and supports custom authentication schemes. All data stored in Firebase is replicated and backed up to multiple secure locations, and Firebase manages millions of concurrent connections and billions of operations. 

Sadly, Firebase currently runs only in its own public cloud and doesn’t offer a choice of storage locations. I can’t see using Firebase for applications that need to comply with the HIPAA, PCI-DSS, or FIPS standards, or for data that needs to be stored within the EU.

Firebase has libraries for all major Web and mobile client platforms and bindings for the most popular frameworks, plus a REST API for otherwise unsupported platforms. It has nice quick-start guides for iOS and Android, and it integrates with AngularJS, Ember.js, React, and Backbone.js via supported libraries, which all look pretty good. It integrates with Polymer through a third-party library. 

Firebase can integrate with Ruby, Node.js, Python, Java, Clojure, PHP, and Perl servers through third-party libraries or its REST API. You’d have to use your own server (or Google App Engine) for any back-end integrations you need, because Firebase itself offers no database or application integrations. 

Firebase offers limited hosting (1GB to 10GB, depending on your plan), which would be all you need for, say, a ReactJS app. The hosting is for static files and automatically includes SSL encryption and CDN geographical distribution of the hosting sites. You manage your Firebase hosting with command-line site management tools that you install with npm, the package manager for Node.js.

Firebase-powered apps work offline, as the local storage acts as a cache for the cloud store. You can use the Firebase APIs normally while the device is offline; once connectivity is reestablished, the app will receive the appropriate set of events so that the client "catches up" with the current server state, without your having to write any custom code.

I went through all the Firebase documentation and tutorials in a couple of hours. From there, I downloaded the Office Mover 5000 sample (Figure 3); looked at the code for iOS (Figure 4), Android (Figure 5), and Web (Figure 6); and tried to build the projects for iOS and Android. I was able to build the Gradle-based Android project with Android Studio successfully after updating some of my Android tools and frameworks. I wasn’t able to build the Swift-based iOS project, as some of the Apple UIKit classes have pointer members; the necessary changes seem small, however. 

For what it does -- implementing low-latency NoSQL storage and simple login services -- Firebase is very, very nice. However, Firebase lacks many of the services and deployment options commonly expected in enterprise MBaaS platforms. On the gripping claw, you can use Google App Engine with the Google Cloud Datastore as the database and build an interface between the server and the app as a REST API using the Google Cloud Endpoints framework. 

Microsoft Azure Mobile Services

When the Windows Azure cloud was first introduced, it was basically all-Microsoft, all the time. All of the tooling ran in Visual Studio, and all of the services grew out of Windows servers, although with enough differences to make using the APIs a challenge. In those early days it could take as much as half an hour to provision a service; now it typically takes less than a minute. 

The renamed Microsoft Azure still has plenty of Microsoft services, but it’s no longer exclusively a Windows-oriented system. Do you want a CoreOS VM? No problem. Need a MongoDB or Cloudant NoSQL database? Got it. Even though the Visual Studio tooling integration with Microsoft Azure is better than ever and supports Visual Studio Online, I did my current evaluation on Mac OS X Yosemite using Chrome for a browser, as you’ll see in the screenshots. 

Microsoft Azure Mobile Services provides a full-featured MBaaS, hosted on the Azure public cloud, with data centers in 19 regions around the world. Azure allows for hybrid clouds through hybrid connections between Azure and your data center -- to connect an Azure website or mobile service to an on-premise SQL Server, for instance, or to set up a hybrid HPC compute cluster. Azure supports multifactor authentication and has been used for many applications in regulated industries (such as health care and finance) and geographies (say, the EU).

Microsoft Azure Mobile Services supports iOS, Android, Windows Phone, Windows Store, Xamarin iOS, Xamarin Android, HTML, PhoneGap, Sencha, and Appcelerator clients. On the back end, you can host a .Net or Node.js Web API with 24/7 monitoring and management. No matter which client and server technologies you choose, you can use single sign-on with Active Directory, Facebook, Twitter, and Google; send push notifications to individual users and dynamic audience segments; store data in SQL, Table Storage, and MongoDB; access on-premises systems, Office 365, and SharePoint; and use cloud-based sync to build apps that work offline. 

Azure and Azure Mobile can be managed from a command line (Figure 7) or the Web console. Creating an Azure Mobile Service also generates an Azure SQL Server database and a mobile hub for push notifications. While you can use an existing database if you wish, it should be in the same region as the other services to minimize the interservice latency. 

Once you have created a mobile service, Azure offers to create a starter to-do app (Figure 8). One of the steps in creating the app is to create a SQL database table for it, which you can view from your own computer once you authorize your IP address. Azure makes that easy, by telling you the IP address you’re currently using and asking if you want to authorize it for management. Note that I’m browsing the database (Figure 9) from an open source Java application on a Mac, not SQL Server Tools or Visual Studio on a PC.

Some people will react badly to the idea of using a SQL database as a mobile back end rather than a NoSQL database. Honestly, both work fine, and this SQL data design allows for clean version tracking and timestamps, which help with conflict resolution. 

I looked at the generated starter apps on iOS in Swift, which had a compiler error, and Android, which did build once I changed the target version to an SDK I actually had installed. You can easily add back-end storage to an existing app (Figure 9) using the supplied code as a template.