Pulse on Kindle Fire: powered by Google!?

The big news when Amazon launched its Kindle Fire tablet in September was that its web browser, Silk, is powered by the Amazon Web Services cloud. But don’t think AWS is the Kindle Fire’s only connection to the cloud. In a post on Tuesday on the Pulse Engineering Blog, Pulse’s Greg Bayer explained how his company’s news-reading app — one of three preloaded on the Kindle Fire — actually runs atop Amazon competitor Google’s App Engine Platform-as-a-Service offering.

Not that it should come as a surprise. PaaS options are increasingly becoming the option of choice for mobile apps, and even dynamic web apps, and App Engine — despite some recent concern over price hikes — is about as good a choice as anything else. Pulse actually has been using App Engine all along for the iOS and Android versions of its reader, but its use for the Silk version is notable because Amazon — which has decided to make Pulse a star on the Kindle Fire — has its own suite of cloud services to sell developers.

But as Bookish CTO Andy Parsons said at October’s Surge conference about his company’s reliance on AWS, “[T]he devil you know is better than the devil you don’t.”

All about the architecture

That being said, Bayer does note that using App Engine had some very real benefits that directly influence its presence on Amazon’s device. Because Pulse is one of three apps (along with Facebook and IMDb) preloaded on every device, the team had to prepare the app to handle significantly more traffic in a hurry. With Kindle expected to sell 5 million units during the fourth quarter, Pulse will be doubling its user base in just three months and will likely be serving hundreds of millions of requests per day.

Luckily, Bayer writes, App Engine is up for the job — if you architect your application correctly:

While restrictive in some ways, we’ve found App Engine’s frontend serving instances (running Python in our case) to be extremely scalable, with minimal operational support from our team. We’ve also found the datastore, memcache, and task queue facilities to be equally scalable.

About those new App Engine prices

As some might recall, there was quite an ado among the App Engine developer community in September right before new prices and features were set to take effect. Some developers who had been running apps for next to nothing (justifiably) feared they would be priced out of continuing to use the platform — a pretty scary proposition considering the degree of customization App Engine can require.

Bayer explains in his post that Pulse shared in those concerns, and its attempts to determine the ultimate cost of using App Engine resulted in the development team uncovering some inefficiencies in the application code as well as in the new App Engine scheduler. However, Bayer writes:

By doing some testing to find the optimal cost vs spike latency tolerance and setting the sliders to those levels, we were able to reduce our frontend instance costs to near original levels. Our heavy usage of memcache (which is still free!) also helps keep our instance hours down.

The data store appears to have presented a trickier situation, because database usage used to fall into the flat hourly rate for the App Engine service. Presently, Pulse is working to drive those costs down as much as possible by streamlining the connections between its logic and data tiers.

Pulse also did something smart that had little to do with technology: It contacted the Google App Engine support team to let it know that Pulse’s app should be experiencing increased load as Kindle Fires start shipping. It also signed up for a premier account, which means simpler billing options and support from Google engineers. As the hype around so-called enterprise clouds illustrates, the do-it-yourself nature of cloud computing is great until your business relies on it. Then you might be willing to shell over an additional $500 per month.

Nothing’s perfect

If you read Bayer’s entire post, you will get the details on how, exactly, Pulse was able to tweak its App Engine strategy and code, but you will also get his thoughts on where App Engine can improve. Although it seems like we’ve been talking about it for a decade, cloud platforms like App Engine, and even AWS, are still fairly new, and they’re far from perfect. But if a platform is generally good, it probably makes sense to accept its shortcomings and grow with it, lest risk moving to another provider and dealing with a whole new set of issues.

Also, while Pulse likely didn’t build its application on App Engine with the Kindle Fire in mind, its decision could prove wise regardless. If Amazon’s cloud goes down, Silk will run slower for those who turn on the cloud enablement, but Pulse will still run as usual. Companies running their applications with PaaS providers such as Heroku, AppFog, DotCloud or any other number of AWS-hosted platforms might not be so lucky.

This actually is a concern that exists outside application development, too. My colleague Stacey Higginbotham recently covered a startup called Spanning that uses AWS to build a backup for consumer data stored in Google Apps. Cloud platforms might not be too interoperable at this point, but with clever engineering, one certainly can be used to backup or complement another.