Microsoft DevRadio: (Part 1) Using Windows Azure to Build Back-End Services for Windows 8 Apps

The Discussion

• 

  Azure backend is great, but here is a million-dollar question: which Win8/WP8 payment model does actually support Azure costs which are in their nature per-usage?

  Neither a subscription-based payment model nor in-app feature purchases can address the issue of per-usage costs. Why isn't there a pay-as-you-go model that would allow users to purchase some sort of credits, which would then offset Azure traffic/storage costs?

  As it stands, there's no point in building WP8/Store applications with Azure backend because it is financially unsustainable business model.

  ▼

  ▲

• 

  vkdev,

  Actually, with the exception of Azure Compute, most of the services I discuss in the series are either free or charged on a monthly basis.

  I do use the Azure SQL Database, which is charged monthly, for data storage. The same SQL Database, however, can be used across multiple services.

  Windows Azure Mobile Services and Windows Azure Web Sites (the latter is what I use for the ASP.NET Web API version of my back-end service) are both available as free offerings in shared mode, so assuming you used the Azure SQL Database offering for the data storage, your cost would only be $10/mo.

  You can find pricing details for Mobile Services and Web Sites at:

  http://www.windowsazure.com/en-us/pricing/details/#data-management/
  Hope that helps!

• 

  Thanks for the info.

  I'd say that the choice of the payment model has to be figured out very early in the development because it greatly affects the overall cloud application architecture.

  Even if one starts with free services and/or by paying (I assume you meant fixed) Azure costs on a monthly basis, scaling up (which is why Azure is the choice for the back-end) will inevitably push people towards shared or reserved instances and, essentially, pay-as-you-go costs.

  By the time one realizes that the scaling up implies switching to a different payment/business model because the costs are, after all, per-usage and not fixed nor regular, it will be too costly (or even too late) to go back and try to retrofit into the application architecture a different payment model in order to offset those costs.

  In fact, at the moment there does not seem to exist such a model which would match pay-as-you-go on the back-end side.

  Speaking of which, I just started looking at the WP8's Wallet functionallity, specifically OnlinePaymentInstrument. Perhaps that can be used as a way to maintain some sort of a user account balance, which can increased with occasional payments (i.e. pay-as-you-go).

  The trouble is, there is no equivalent functionality on Win8, but that's a problem for another day.

   

   

  ▼

  ▲