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 yesterday on the Pulse Engineering Blog, Pulse’s Greg Bayer explained how his company’s news-reading app — one of three preloaded on Kindle Fire — actually runs atop Amazon competitor Google’s App Engine platform as a service.

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 an option 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 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 benefit 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 likely 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 take effect. Some developers who had been running apps for next to nothing (justifiably) feared they’d 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 datastore appears to have presented a trickier situation, because database usage use 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 its the connections between its logic and data tiers.

Pulse also did something very 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 Fire’s 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 actually be willing to shell over an additional $ 500 per month.

Nothing’s perfect

If you read Bayer’s entire post, you’ll get the details on how, exactly, Pulse was able to tweak its App Engine strategy and code, but you’ll 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 shortcoming 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 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 of application development, too. My colleague Stacey Higginbotham recently covered a startup called Spanning that used 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.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

  • Infrastructure Q3: OpenStack and flash step into the spotlight
  • Infrastructure Q1: IaaS Comes Down to Earth; Big Data Takes Flight
  • Infrastructure Overview, Q2 2010



GigaOM