Cloud services for mobile developers: Google vs. Amazon vs. Azure vs. Parse

Previous 1 2 Page 2

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.

ParseParse 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 secret to this cross-platform reach is a JSON-based key value store with something that looks very similar to Node.js acting as the gatekeeper. You write your functions for the server in JavaScript. The folks at Parse have bundled together most of the major features of Node.js, including modules for connecting to major services such as MailChimp and Twilio.

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 mobileFiguring 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.

The part that stood out was Microsoft's packaging of a JavaScript server -- one of the nicest and most flexible options. It doesn't offer any fancy debugging support or the ability to dig into the complex guts of the system, but you can accomplish something quite useful without worrying about any of those things. It won't offer enough flexibility for people with complex apps, but it might be a mistake to get hung up on this. Much can be done with the basic building blocks. It may make the most sense to just embrace the simplicity and redesign the app to match it.

• Huge variety of services
• Tools include ways to enhance existing services for mobile use
• Industry-leading infrastructure with deep access to underlying instance layer

• Broad collection of APIs, including essentials like maps
• Continuous queries offer sophisticated filtering/pipelining
• Rich tools suited to larger teams building reliable applications

• A clean way to build simple Web services based on JSON calls
• Essentially an interface to Node.js
• Provides code editor in your browser

• Well-integrated collection of libraries supports numerous mobile platforms
• Extensive documentation
• Nice aesthetic makes it simpler to create good-looking apps

• Size and complexity can be daunting
• Instance focus can require more work

• Mostly Java-based and complex
• Plenty of interaction with Google Play Services

• Tilted toward Microsoft tools and languages
• Lacks robust debugging

• Command-line focus
• Prices are transparent for Basic and Pro levels, but not for Enterprise level

This article, "Cloud services for mobile developers: Google vs. Amazon vs. Azure vs. Parse," was originally published at InfoWorld.com. Follow the latest developments in cloud computing and application development at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

Read more about cloud computing in InfoWorld's Cloud Computing Channel.

This story, "Cloud services for mobile developers: Google vs. Amazon vs. Azure vs. Parse" was originally published by InfoWorld.