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.
This becomes obvious once you start customizing the mobile services by adding logic. If you click on Insert, you're given a field in your browser with a starter function written in JavaScript. You can manipulate the data in any way you want before passing it on to the code that will write it to the database. You can filter the data, check for errors, and add custom fields like time stamps in a few lines of JavaScript. When you hit Save, Windows Azure Mobile Services turns this into Node.js code.
This is a clean way to build simple Web services. You edit the JavaScript functions, and the Web back end packages them for Node. I had a great time until I started making mistakes -- there's not a great deal of debugging support. The code either works or it fails. When I left off a curly bracket, everything stopped functioning until I figured it out. The Web interface is fine for basic tools and quick front ends, but you can't build long, complicated filters on the data.
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.
Not every part is so simple or accessible. The push services are mainly for Windows apps. It's simpler to build them with Visual Studio. These can be linked with Apple's and Google's cloud messaging systems too with a bit of work. The programming on the Azure server is done in JavaScript, and you merely insert a library to send a message to the right channel ID. The programming for the client, though, is trickier and more involved.
There are more parts to Azure Mobile Services, and Microsoft is continuously adding to the stack. Features like scheduling and scaling are listed as "previews," though they seemed to work. The scheduled job is a JavaScript function, while scaling changes the capacity level of the service tier.
The entire package shows what can be done with JavaScript. If you're comfortable with the language, you'll enjoy spinning up fairly complicated systems with a few functions and some inputs to the forms. It's quite easy to add simple business logic to funnel data in and out of the databases. If you don't like JavaScript -- well, it's not too hard to learn what you need for this.
I suspect that more ambitious projects will rapidly hit the limits of this system. If you think you'll need to rework a low-level call or add complicated logic, you'll probably start to encounter the restrictions of putting some JavaScript into a text field of a browser. But you can do quite a bit with what Microsoft provides here.
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.