Building for Cost Part 2

In the last post, we looked at ways to separate content using different pieces of Windows Azure for the benefit of creating a more cost-effective solution using Windows Azure Web Sites (WAWS) and Windows Azure Storage for storing images and other binary/static files.   Although we’re looking at this just for cost efficacy, frankly that approach just makes sense from an availability and performance aspect, too.

Another fantastic service is Windows Azure Mobile Services (WAMS), but unsurprisingly, it has its own cost structure outlined here:

Similar to WAWS, you can have up to 10 services for free.  But, the way these services are metered are completely different, and it might change the way we build an application.

First, let’s discuss the free tier.  The current metering, limited to 100 devices, means that using an authenticated client (that is, any client using the SDK) renders this tier useless for anything other than testing.  For example, here’s my low-use application:

We’re not really incurring many API calls, but our device count is pretty high.  When I designed the app, these meters weren’t in place, but if they were I’d design the app differently.  Hopefully, we’ll see some changes in this as the current plan is a bit inflexible.  What this means, though, is that for my app to keep working, I need to upgrade to the $25/mo plan. 

By making a few specific decisions early on, we can build the application to take advantage of both WAMS and WAWS.  For example, in WAMS, custom API calls can be made and invoked over HTTP.  I leveraged this in Brew Finder for several items: brewerydb’s callback, live tiles, and web services that don’t require authentication.  Because these calls are made from “non-devices,” the usage looks like so:

I’m not exactly sure why this is showing zero bytes out (it could be for the time duration shown in this graph, it’s not significant enough), but the 0 devices and API calls count is accurate.  We also have the option to deploy another WAWS with node.js, if we’d like to stick with server-side javascript.  Remember, the database that is used can certainly be shared by any number of WAWS, WAMS, etc.  So, if you need to curb back on your API calls, offload that work to a WAWS instead where the calls are not metered if you don’t need WAMS specific features (like authentication). 

Summary

The biggest challenge in developing a cloud backed app is guesstimating the usage.  The first step, though, is to understand what is being measured – API calls, devices, bandwidth, CPU time, etc.   Keeping the application architecture spread across multiple services for different functions (authentication, live tiles, etc.) is a great way to make the application flexible so you can take advantage of the way each service is metered, bearing in mind this is always subject to change.

Having trouble estimating or getting started?  Drop me a note or leave a comment on this post.  I’d be happy to help you work through some ideas.