Scaling the cloud, deflating the price of software

Two separate but complementary phenomena in combination seem to radically undermine traditional on-demand pricing models, giving rise to a new economic reality for cloud-based application software.I learnt of all this back in January, and I've since been biding my time until last week's launch of the Amazon-hosted product [disclosure: for which, as a paid engagement, I've written a white paper (PDF)]. I've been eager to write about it because the story highlights t

After a week of intensive usage last December getting his company's application to run against Amazon's SimpleDB cloud database, DreamFactory founder and CTO Bill Appleton wondered how big a bill he'd run up. To his amazement, what had seemed like a week's heavy usage had cost just a few cents. The discovery was an epiphany both for Appleton and for CEO Eric Rubin. They had stumbled upon what seemed to be a new economic reality for cloud-based application software.

I learnt of all this back in January, and I've since been biding my time until last week's launch of the Amazon-hosted product [disclosure: for which, as a paid engagement, I've written a white paper (PDF)]. I've been eager to write about it because the story highlights two separate but complementary phenomena that in combination seem to radically undermine traditional on-demand pricing models.

First of all, as Appleton told me in January, "Usage-based pricing is as disruptive to on-demand as on-demand was to enterprise software." On-demand pricing of anywhere between $30 and $300 per user per month has challenged the high implementation and maintenance costs of conventional on-premise software. But now there's a new threat to the traditional monthly per-user subscription pricing model for on-demand applications, in which every user has typically paid the same flat (or should that be fat?) all-inclusive price, irrespective of usage.

Appleton's words were still ringing in my head in April when Bungee Labs [disclosure: which paid me to record a podcast] switched to usage-based pricing for its cloud-hosted application development and deployment platform, resulting in monthly per-user pricing as low as $3.60 for intensive use and anything from $0.48 down to a mere $0.02 for occasional use. That's at least a tenth — and at the extremes as much as a ten-thousandth — of the traditional all-inclusive monthly per-user fee for on-demand software.

Monthly pricing for DreamFactory's DreamTeam Suite is $12.95 per account, plus Amazon usage fees per user, which DreamFactory says "per month should be no more than cup of coffee." Per enterprise — with unlimited administrators, projects and users, private training and live support, is $89.95 plus Amazon usage fees per user. What DreamFactory has done is split off its software licence fee — at either $13 or $90 per account depending on complexity — from the Amazon-supplied computing cost. The outcome is a truly commodity price per user.

Of course this is only applicable for forms-plus-database applications like DreamTeam project management, as opposed to the more complex transaction capability that's platform offers these days (and which vendors such as CODA are tapping at a monthly per-user price well below $20). But for applications like DreamTeam it makes no sense to stay at the $20 per user level of Apex and AppExchange when they can be hosted at Amazon Web Services for a fraction of that monthly cost. DreamFactory is also working on a version for Google App Engine, whose database costs are said to be a further ten times less than Amazon SimpleDB.

The challenge for software vendors is that a lot of these pricing differentials are purely due to how they decide to price their assets. Salesforce has to charge the highest price because it pays Oracle for a commercial database license. Amazon runs an open-source database so can charge much less. Google thinks of its database as more as a file system so sets its charges lower still. Is there a quantitive difference between any of these three infrastructure alternatives?

The second element of DreamFactory's secret sauce is that its local client architecture means that it has to maintain minimal infrastructure of its own. "We're using other people's servers and our customers' clients and it drives the cost into the ground compared to enterprise applications," Appleton told me back in January. Others are starting to grok what Appleton has long known — consider this recent post by Dion Almaer (which I discovered via the always-perceptive Dare Obasanjo):

"Gears is so much more than offline, and it is really exciting to see 'Speed Up!' as a link instead of 'Go Offline?' ... With an embedded database, local server storage, worker pool execution, desktop APIs, and other exciting modules such as notifications, resumable HTTP being talked about in the community ... I think we can all get excited."

What's really exciting about Gears, DreamFactory, AIR and Silverlight is the ability to use the client's processing resources instead of exclusively overloading the server side of the infrastructure (the architectural failing that has made Twitter suffer so much of late).

Appleton believes that DreamFactory has struck this balance perfectly, keeping the vendor's own infrastructure overhead predictably low while at the same time leveraging client resources to extract maximum value (at minimum cost) from whichever on-demand server resources offer the best fit for DreamFactory's applications.

DreamTeam currently works with AppExchange, Intuit QuickBase, Amazon Web Services (including SimpleDB) and WebEx Connect, with Google App Engine support in the pipeline, and every intention of connecting to Microsoft's Live Mesh and any other useful cloud resource that emerges. This notion of a cloud-neutral client that ports functionality to wherever it offers most value is intriguing and different from everything else that's out there (though Gears is perhaps the closest in spirit). I believe it has huge potential — especially in driving forward the commoditization and price deflation of on-demand functionality.


You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
See All
See All