The victory of the mobile platform has wrought many changes in the enterprise world. Emails are now more succinct because no one can type at length with the tiny keyboards. Web pages are simpler because no one's eyes can read all the detail on the tiny screens. And the cloud is essential. Mobile phones and tablets can't exist without a healthy collection of services from distant machines in faraway racks.
The cloud was always a good idea, but now it's indispensable. The ability to poke around in the file system of a desktop machine is an awesome freedom -- and a great responsibility. The desktop world still operates under the rules of living created during the frontier days of the early personal computer. They're your files; now show some gumption and take care of them.
The mobile operating systems make rugged individualism all but impossible. Mobile users can't manipulate files or handle their own data unless they take extreme measures and root their phone. Maybe it evolved that way by accident because the early handsets were so relatively dumb. Maybe it was by design because Steve Jobs knew smartphone users didn't really want the traditional power given to desktop users. Maybe the smartphone creators were channeling Jack Nicholson in "A Few Good Men" because they knew we couldn't handle it.
In any case, it's now impossible to build almost any significant app for the mobile world without a stable connection to a reliable back end in the cloud. Email and notes better be stored somewhere because someone will drop a phone in a toilet, a lake, a puddle, a pot of soup, or who knows what. Even the little games for wasting time in the back row of class need to keep a user's history. Desktop games could store max scores on the local disk, but that doesn't work with phones. All of this data needs to live somewhere besides the handset.
The good news is cloud companies are ready to help. In the early days, you could always set up your own server, hook up your own routines, and start your own databases to take care of the mobile clients. Now Google, Amazon, Microsoft, and startups like Parse (acquired by Facebook last April) are stepping up to offer more of a turnkey system. They've built another layer of data services on top of their basic machines, and they're selling them to developers who want to buy a back end, bit by bit instead of wholesale. The packages do a good part of the work you'll need for your application and give you the ability to scale.
What follows is a tour through these four clouds that offer APIs they call "mobile services" or "mobile back end as a service" (MBaaS). While mobile services might sound completely new, in reality these clouds are mixing a number of old tools with a smattering of new ones, then stamping the result with the keyword "mobile." This isn't a shabby play on our gullibility, but a savvy repackaging. Desktops and other machines need many of the same services. After all, the only differences between mobile and desktop are often the size of the screen, the keyboard, and the pointing device. To a data center, the devices are exactly the same. It's not surprising that many of these APIs recognize that fact.
Microsoft Windows Azure Mobile Services
Windows Azure is the brand name that Microsoft wrapped around its cloud of raw compute power and data storage. In one corner of a growing collection of tools sits the mobile services, a collection of routines that funnel JSON packets of information in and out of Microsoft's cloud databases.
The name illustrates what happens when MBAs sit around the table and talk about brand names. Not everything in this cloud has much to do with the operating system known as Windows. All of the traffic in and out travels as open standards and much of the infrastructure is open source. The selection menu for the operating system on the virtual machines for rent starts with Windows Server, but it also includes Ubuntu and Oracle Linux. The identity manager supports log-ins using a Microsoft account, as well as accounts from Facebook, Twitter, and Google. The Azure team clearly wants to be open to anything the customers desire, but the brand manager probably thought that tossing in the word "Windows" would act as leverage or a brand extension.
This split between the Microsoft gated community and the open Web became more apparent as I dug deeper. Much of the documentation encourages the programmer to use Visual Studio to create everything. I clicked on the download button and settled in to wait for more than 3GB of files to arrive.
While waiting, I poked around with my Linux box and discovered that I didn't need Windows or Visual Studio to enjoy the marvels of Windows Azure Mobile Services. Following a few clicks in a browser window, I configured and tested a fat database table sitting in Microsoft's cloud absorbing the data I sent its way. My download meter on the Visual Studio was only up to a few hundred megabytes of data, but I had a running back end for my mobile apps. I canceled the download.
The secret is that Windows Azure Mobile Services is a beautiful front end on Node.js. The logo on the top is from Microsoft central branding, but it takes only a few minutes to realize that almost everything underneath is Node.js acting as a gatekeeper to a Microsoft SQL database.
The Windows Azure dashboard graphs usage and tracks data flows for all of the services.
It's worth noting that you don't need to handle many of the details. When I added extra fields to the packet of JSON data I sent to the server, new columns to store them magically appeared. The back end does much of the work and makes the process much like using one of the unstructured document stores like CouchDB. It's possible to go a long way with little code.
Azure simplifies the process by giving you a template for all of the code needed for six platforms that range from Windows to iOS to Windows Phone 8 to Xamarin. In each of them, it takes only a few lines to add the right libraries and a few more to store data. You don't need Visual Studio for any of this.
I'm not sure how this will go over with the brand managers who want to deploy concepts like "brand extension," but I liked using the mobile cloud with a simple HTML5 app. Microsoft did a great job opening this up to everyone, which means it'll be easy to use for projects that need to span the traditional Web, the legacy desktop machines, and the new world of mobile apps.
Google Mobile Backend Starter
Google offered one of the first app platforms sold as a metered service: App Engine. Now Google wants to be the mobile back end as well, and to do this, it has bundled together some of its existing cloud infrastructure. Google already had a storage engine with a REST API, an authentication system for your Google log-in, and a messaging system. Turning it into a cohesive mobile product wasn't hard.
The basics for a mobile app can be built with any of these parts. Google's collection of APIs is huge, and it's always been a good start for any app or desktop tool. It's easy to begin storing information in the Google cloud with just a bit of work.
The Mobile Backend is focused more on messaging, authentication, and continuous queries, the last being a tool for dealing with the endless stream of information from the hypersharing world. While the App Engine will accept code in PHP, Python, and Go, all of the examples for the Mobile Backend come as Java.
Digging into these tools was surprisingly onerous. After hours of downloading plug-ins for Eclipse, I couldn't get the libraries and the code into a magic alignment. A big part of the problem was the Google Play Services, the closed source pathway for more and more of what we think of as Google. There will always be debate about the right amount of openness, but I spent hours trying to get the library to install. Part of the problem was that the simulators now come in two flavors: Google and Android. Keep the difference straight because the code won't run on Android alone without Google Play Services.
Google's Mobile Backend API Explorer lets you test and debug your API calls.
The newer features are fascinating and a bit scary. Google wants to compete with some of the newer, seemingly continuous services like Twitter. If you write one of the new continuous queries, you can ask App Engine to search either the past, the future, or both. The searches of the future don't use a time machine; they just sit on the server waiting for new data to be stored. If the new information matches the query, it's pushed out to the client. The documentation notes there's a current limit of 10,000 clients who can be waiting. You won't be spinning up a project as big as Twitter right away, at least until Google deals with this limit.
The documentation comes with a warning that is meant to scare off the casual coders: "Prospective Search is an experimental, innovative, and rapidly changing new feature for Google App Engine. Unfortunately, being on the bleeding edge means that we may make backward-incompatible changes to Prospective Search. We will inform the community when this feature is no longer experimental."
What does this mean? App Engine itself is still listed as a "preview" in some screens. Will things really change? No doubt Google will do its best to make sure the platform remains as stable as possible, but some elements of the cloud are clearly a work in progress.
Using any of the additional Mobile Backend features is a good lesson in why Java development remains an expensive process privy to only those with plenty of time and money. The tools are complex, and the code is long and elaborate. The code for deleting a blob from Google Cloud Storage, for instance, includes a loop that will try deleting five times in case the API is overwhelmed or unavailable. It's laden with blocks to handle many types of exceptions. The richness will be useful for larger teams building reliable software with high availability, but it's not a simple process.
Of course you don't need to dig this deeply to enjoy the riches. There are dozens of APIs -- Maps, Calendar, Contacts, Drive, Hangouts, and so on -- and most of them have some real value for the mobile world. All of these different elements should be considered part of the mobile offerings even if they're not in the official list of so-called mobile services.
AWS Mobile Developer Center
While the other clouds have specific products aimed at mobile developers, Amazon's Mobile Developer Center is little more than a pointer to regular services for any machine on the Internet. There are dozens of APIs for Amazon Web Services; a few of them are also ideal for mobile devices.
Amazon lists its federated log-in system, databases, and push notifications as the services for mobile apps, but I think it's selling itself short. Amazon Web Services has a number of different databases that aren't even listed here, and some, like SimpleDB, are good matches for the kind of lightweight apps that often live in the mobile space. If you're a fan of Postgres, Amazon is now offering that in the cloud too. I'm not sure mobile users on the go have the patience to wait for Amazon's Glacier, a supercheap storage service that measures its service guarantees in hours, but maybe some users would want it. My suggestion is to skim the Mobile Developer Center and look at the entire list of Web services.
The Mobile Developer Center does highlight several ways to enhance the services for mobile apps. Amazon's Geo library adds location-based queries to its NoSQL database service, DynamoDB. This saves you the trouble of hacking up the different schemes for testing proximity to latitude and longitude pairs, which can be a bit of a pain.
The docs also show how the simple notification service can be used for sending push notifications to smartphones. Amazon's Simple Notification Service is a wrapper around Google Cloud Messaging, Apple's Push Notification Services, or Amazon's own Device Messaging. You write to one place, and the text goes out to all subscribers, be they iPhones, Android phones, or Kindle Fires. It's one way for Amazon to promote its devices by supplying the glue code.
High scores for a SimpleDB-backed game app running on the Android simulator.
It's worth noting there are quite a few options in the messaging stack, including the ability to deliver notifications to Web servers and email accounts. You can even format a message in JSON and send it to an email account. Oddly enough, if you confirm your email subscription delivered in JSON, the response will be in XML, but I'm sure there's a way to sort that out.
It's almost impossible to cover all of Amazon's offerings here. While some are geared more toward servers, most have some application to the mobile world because the mobile world is filled with Unix boxes that fit in our pockets masquerading as phones.
There is one new offering, though, aimed directly at small handsets. The new AppStream service is designed to let you compute the imagery in Amazon's cloud and continuously ship the image to the handset. The Amazon cloud instance acts as the CPU and video card, while the handset is simply the display. Amazon promises to handle network lag and low bandwidth by adjusting how many bits are delivered. One of the selling points is that developers can aim high and produce a visually rich world that will look great to people with expensive handsets and fat pipes and merely OK to those with cheap handsets and slow connections. Your great graphics will be rendered on Amazon's cloud and made visible even to customers with low-end phones.
I'm sure AppStream will be compelling to developers who can't get the tiny mobile handsets to push enough triangles to create a suitably scary villain, but I have to wonder about the costs of bandwidth and CPU time. The price for AppStream alone is 83 cents per hour. To compare, a new Xbox or PlayStation costs less than a dollar per day if you amortize it over two years. Even when you add in the cost of the games, it seems cheaper to ship some hardware to the client. But maybe AppStream will end up being more competitive when the price of bandwidth drops and people demand even better games.
Parse may not have as big a name as the others in this review, but it offers a solid collection of back-end services as well as libraries for accessing these services from all of the major and not-so-major platforms. Once you build your tables full of data on Parse's server, the info can be pushed and pulled from platforms ranging from iOS and Android to Unity and Xamarin. Parse is a fast way to build a back end that services apps running across all of these platforms.
The eight different libraries for the various clients are packages that bundle the data into JSON, ship it to the Parse servers, and unpack the result. They're glue wrappers for moving data around as JSON packets. You could accomplish most of this with many other stock libraries, but they wouldn't make authentication as easy.
The Parse push system targets the subset of platforms that support push notification: Android, iOS, Windows Phone, OS X, and Windows 8 desktops. Most of the work occurs outside of Parse because the different platforms require certificates and configuration, all of which is described in detail in the documentation. Once you jump through the hoops, you should be able to send notifications from any of the platforms and to anyone subscribed to a channel.
Parse's data browser lets you mind your Parse tables over the Web.
One of the nicer features is comprehensive user management that includes hooks for working with Facebook and Twitter. The user authenticates through Facebook or Twitter using OAuth, or you log in with a password set up for your app alone. The access for each object in the database can be controlled using a permissions matrix that's based on either the local Parse username or the Facebook name. This allows you to piggyback on Facebook authentication, something that can simplify your app. The Parse library handles the OAuth, something that can be maddening to write from scratch.
Despite all the pretty Web screens for browsing the data, working with Parse is surprisingly text-based. I edited the control logic in an editor and pushed it with a command line. Debugging was best handled with the log files and messages. Tracing the path through long functions isn't really possible without installing much of the code locally.
There are many reasons to embrace a platform like Parse. If you're looking to store tables for your apps and wrap a bit of logic around them, Parse lets you pull this off in a few minutes, in part because the documentation is so extensive. Thanks to the extra libraries, it's pretty easy to push notifications, email, or phone messages to others.
The system should scale reasonably well, but it's easy to see how some complex tasks might fail. According to the documentation, the basic functions are "killed after 15 seconds of wall clock time." Functions that run before and after saves to the database only get three seconds to live. I can understand why the developers chose what sound like arbitrary limits. It's the simplest way to maintain boundaries between so many apps living together on a shared box. But it sure makes complex systems less predictable when resources become tight.
It's hard to know whether you can take much of your Parse code with you if you decide to move to your own servers. Of course if you're building a lightweight app that doesn't store too much, you'll be fine. If it's all simple tables, you can be up and running in little time.
Pick a PaaS for mobile
Figuring out the right way to use the cloud to support mobile apps is now a key part of the development process. All four clouds offer solid solutions for squirreling away data in case someone's kid drops the phone.
There are other solutions of course. While researching this story, I was building an application that needed cloud storage. For my mobile back end, I ended up installing Drupal on a spare server. It was neither as clean or as organized as Microsoft's back end, nor as well documented as Parse's, but it wasn't hard to get something running that would handle the data I was sending its way. All it takes is a module that adds JSON Web services to Drupal. The best part: It also came with all of the display code for browsing the data and presenting it in a nice way. There are hundreds of themes for Drupal, so creating a nice look isn't too hard.
My traditional Web stack can't push notifications, but I'm not sure they're necessary for many applications. It's much simpler to ask the client to poll the server periodically. It may not be as interactive or as instantaneous, but it's simpler than jumping through the hoops the different push systems require.
It's not always as easy to scale code like Drupal either, but it can be simpler and more flexible. Google's App Engine stack, for instance, isn't particularly portable. If you decide you don't like Google's cloud, you'll need to do quite a bit of coding. Microsoft's Node.js code is probably the simplest to move if needed.
In the end, all the APIs offer a substantial boost for anyone building a basic database-backed server, which is the bulk of the job for mobile code. The job of pushing data to the users, though, is still a work in progress. The code was messy and the APIs complex. Much of it is still experimental. It's not simple to create something that will push bits to millions of clients, even using these tools.
Mobile back-end services at a glance: See the checklist from the InfoWorld Test Center.
This story, "Cloud services for mobile developers: Google vs. Amazon vs. Azure vs. Parse" was originally published by InfoWorld.