Surprising Costs of Windows Azure Hosted Services

November 19, 2010 Leave a comment

This summer I had a few days to twiddle my thumbs between quitting my job and starting with my new employer, Unstoppable Software. Creative ideas ran wild inside my head, the time off made me feel like I had an infinite amount of time to make them tangible. I whipped up a few websites and wondered where I could cheaply host them since they were built in ASP.NET MVC. Naturally, the first thing that came to mind was to store them in Windows Azure. After all, my BizSpark benefits included a reasonable amount of free service and I wanted to learn more about how the hosting service worked.

At first, this turned out to be a great idea. I was able to quickly get my site up and running in a Production environment on Windows Azure with a custom domain. Best of all, hosting was free!

Getting a working site in Production ended up being my biggest mistake.

I soon realized that I wanted a second hosting environment so that I could test development changes without affecting the working application in Production. Windows Azure’s easy to use deployment interface suggested the creation of a Staging Environment.

Azure Deployment Interface

 

The Staging site worked great. It allowed me to test with a different URL until I was satisfied with the results, then pushing my code to Production. Unfortunately, deploying to a second environment doubled the rate of consumption of a key cost metric, Compute Hours!

A Compute Hour is an hour of application use multiplied by the number of server instances. This is calculated regardless of the state of deployment (Suspended versus Active) and the environment (Production versus Staging). I was very surprised to discover this when I found a charge (below) for Microsoft Online on my credit card statement. Apparently, other developers found out the hard way as well.

Azure Deployment Cost

 

I expected the Compute Hours to be accumulated only by my Production environment. I certainly did not expect my billed rate to increase simply by following the best practice of using a Staging environment to test my application, especially if it was suspended when I was not testing. Additionally, I had incorrectly assumed that Compute Hours were only calculated when my web application was processing requests (of which I was not receiving many). I had not really thought about the cost since hosting was free at first. My recommendation to Microsoft is to make it more obvious to developers that the cost doubles when using an additional environment. I would also like to see a long-term Azure strategy for hosting low-traffic sites. Luckily, I found out about the increase in cost without running up a huge bill.

Advertisement

Filed under Technology Tagged with ,

Implications of Windows Azure Container Types

November 17, 2010 Leave a comment

In 7 Reasons I Used Windows Azure for Media Storage, I described the download process involved in streaming a large video through a Silverlight applet using the Microsoft cloud offering. My scenario involved the use of public containers to store large files (blobs) for a web application. Public containers are convenient because they can be accessed via a simple GET request. Unfortunately, being that simple begets some negative behavior. By being accessible via a simple URL, any user on the web can link to that file and/or download a copy for personal use.

If you are already using public containers, do not be alarmed as if your storage is entirely exposed. I tested my site by typing a URL in which I removed the file name and the result indicated that the URL could not be found. I immediately breathed a sigh of relief. In other words, even public containers do not act the same way that IIS would if the Directory Browsing setting were enabled.

Example URL: http://{ApplicationName}.blob.core.windows.net/{Container}/

Still, for cases in which public containers are not satisfactory due to their openness, the alternative is to use private containers.

Private containers are similar to public containers and remain fairly simple to use. They require the inclusion of a unique key during the GET request for stored files. This is extremely easy using the Azure SDK sample, which abstracts away the details of what must be included in the request.

Effectively, the container type determines where the request for Azure blobs come from. For public containers, the request comes from the client, because a simple URL fetches the file. In contrast, the request for private containers must come from the server. The server-side code embeds the key in the GET request, receives the blob, and processes it or delivers it to the client accordingly.

The obvious benefit to private containers being accessible only to the server-side code is that security logic can occur in it, thereby restricting who can access blobs to specific users based on rules. It also makes it much more difficult, but still possible, to download files stored in private containers for personal use. The drawback to this solution is that streaming now passes through the server, greatly increasing the bandwidth consumed by the application.

As described above, there are cases to be made for the use of both public and private containers. The best solution comes from weighing security requirements against bandwidth and development costs. Of course, there are ways to reap the benefits of both paradigms, but the above restrictions cover the “out of the box” web application scenario.

 

Filed under Technology Tagged with , ,