The Economics of Backend as a Service

Brent Simmons wrote a bit on how common back-end services should be a solved problem by now.  I agree 100%. I proposed something like this when I was at Adobe, when Adobe was trying to build Flash as a platform (which would also have the same sort of requirements), and couldn’t get them to bite on it.  It’s an idea whose had come years ago.

What I envision is a service that provides a core service that takes care of account management, password resets, manages OAuth tokens and all the other core guts that any service needs, and then provides additional higher-level services on top of that.

Image storage, including transcoding and thumbnail generation and other operations.  Blob storage.  Discussion thread management. Video transcoding. Think of a service that’s needed by more than 10 apps, find a way to generalize it, and implement it.

Problem is building and supporting these services costs money. Apple provides iCloud for free to users and developers since it’s subsidized by the hardware, but as Brent points out, Apple has no incentive to make these services available to developers for use with non-Apple clients, so developers need to look elsewhere.

There are some services attempting to solve these problems, but the problem is cost. An app that sells for $3.99 (say, for a “premium” app) has $2.73 profit left, to support the web service back end for the lifetime of the app. It sucks, but that’s reality.

The key to making this work is that your web services need to be incredibly inexpensive to run. 

The pure-hosting services, like linode, make it possible to have a server with a database, bandwidth and storage, that can run PHP or some other low-resource server side technology, very inexpensively.  $20/month and you can have a pretty nice VPS.  You could support thousands of users, maybe even tens of thousands of users, on one of these servers.

But then when you move up to the companies that are selling APIs, like Parse, the price goes way up. The pricing for these services is designed to make cheap or free to get started, but then ramps up as you get more users.  Parse is $199/month when you have over “1 million requests”, which sounds like a lot, but that’s 33,333 requests/day.  If you have 1000 users, that’s only 33 requests per user per day, which isn’t a lot.

And if you’ve only got 1000 users, $199/month is a lot of money.

The only solution that seems feasible to me is an open-source project that takes on the goal of building these services in a manner that’s designed to be easy to deploy on commodity servers.  I wish I had the time.