Windows Azure Guidance – A (simplistic) economic analysis of a-Expense migration

A big motivation for considering hosting on Windows Azure is cost. Each month, Microsoft will send Adatum a bill for the Windows Azure resources used. This is a very fast feedback loop on how they are using the infrastructure. Did I say that money is a great motivator yet? (another favorite phrase :-) )

Small digression: I had a great conversation with my colleague Danny Cohen in Tel Aviv a few weeks ago. We talked (among a million other topics :-) ) about Windows Azure pricing and its influence in design. He told me a story about “feedback loops” and their influence in behavior that I liked very much. I’ve been using it pretty frequently. He wrote a very good summary here.

So, what are the things that Adatum would be billed for in the a-Expense application?

At this stage of a-Expense migration, there are 5 things that will generate billing events:

1. In/Out bandwidth. This is web page traffic generated between user’s browsers and a-Expense web site. ($0.10-$0.15/GB)
2. Windows Azure Storage. In this case it will just be the Profile data. Later it will also be used for storing the receipt scans. ($0.15/GB)
3. Transactions. Each interaction with the storage system is also billed. ($0.01/10K transactions)
4. Compute. This is the time a-Expense web site nodes are up. (Small size role is $0.12/hour) 
5. SQL Storage. SQL Azure comes in 3 sizes: 1GB, 10GB and 50GB. ($10, $100, $500/month respectively). 

Note: $500 for the 50GB SQL Azure instance is my own "linear extrapolation". I don't know how much it will actually be at this time.

Let’s build a cost model for a-Expense.

 

Assumptions:

1. Site will be live 7x24x365.
2. 7 years of data have to be stored.
3. 60% of all Adatum employees submit 10 expenses / month.
4. Each receipt scan weighs 15KB.
5. Each expense record requires 2KB  in SQL.

Compute:

Storage:

Scanned images: 5000 employees x 60% x 10 expenses/month x 15KB x 7 years = 36 GB

SQL Azure:

Expense records: 5000 employees x 60% x 10 expenses/month x 2KB x 7 years = 4.8GB.

This means we need a medium size instance (10GB). We assume we don’t want to partition the database into 5 smaller instances (1GB each).

Bandwidth:

This is almost negligible. This application is rather simple and not very bandwidth intensive. We assume all images generated by expenses are transferred back and forth twice, plus all the web traffic (HTML + graphics). Assuming 4 GB/month in + 4 GB/Month out for all 3000 users:

 

 

 

 

So, total cost to run a-Expense is about: $3400 and  distribution of costs is:

Let’s assume now, that we wanted to double capacity for just 2 days/month (remember that the majority of the users would upload their expenses in the last 2 days of the month). Doing that requires 2 extra machines to be provisioned for those 2 days:

This is a marginal increment of 6.5% of the total compute cost, that probably would result in an improved user experience.

Extremes are useful to test models. With Windows Azure, turning things off is just as easy as turning them on. Is it really needed to have a-Expense available 7x24? What if Adatum decides to make it only available 6 days a week, for 12 hours? including the 2 days a month for increased capacity?

This is just about 50% the original cost.

Astute readers of this have pointed out that it wouldn’t be acceptable for Adatum employees to receive an error when the system is shutdown. Very true. As said, extremes are good for illustration. What I’m trying to highlight here is the elastic properties of Windows Azure and the opportunities it opens for companies like Adatum. Maybe for other types of applications the model could be: 2 servers 24x7, 2 additional servers during work hours and maybe another 4 servers for only 2 days/month. Something like this:

But I’ll confess I liked the concept of “9 to 5” applications! Another solution would be to update the DNS for the app in synch with the shutdown. Users would get a “Sorry a-Expense is closed for today, come back tomorrow”. :-).