Apostol Apostolov

Practical thoughts about software

The experience of Windows Azure websites

Some time ago I wrote about Windows Azure and the experience of hosting configuring an website with a real domain in Azure. The information I posted in that blog post is a little outdated so I thought to update it a bit with more information about the experience I had with Azure since then.

I am using Azure for about  5-6 months now and I’m very pleased with what I get for my money. But let me start from the beginning.

When I started using Azure the only option to hook up a real domain name to a website hosted in Azure was to have a reserved instance and also the only WAY to hookup the domain was to use a CNAME.  So to host my 2 personal apps that only I use and to host this blog meant that I have to pay around 60 €/month for 1 small reserved instance. Now that was a little high so I struggled a bit between paying that rate for a single, not much used website and having the ability to change and deploy the website in seconds.

I was half month paying for reserved instance when I when Scott Gu’s posted the new improvements for Windows Azure. The update consisted of several things, but the ones I cared were the introduction of Shared instance and the ability to hook up a domain name to Shared instance with a A-record. The Shared instance’s cost is 10€/month and the Reserved instance’s cost is around 60€/month. The trick is that with the Shared instance you pay 10€/month once-per-website and the Reserved instance you pay around 60€/month for all your websites.  So if you have more than 6 websites on a Shared instances you may as well buy one Reserved instance for all of them.

With these changes I’m now paying around 10€/month for a Shared instance for my blog and all my personal apps are on free instances(which every account has a limit of 10). So for me the cost dropped from 60€ to 10€ month, and that’s a pretty nice deal for all the features that Azure offers like easy website creation and administration,  one-click deployments from Git and Visual Studio and the one-click scaling of a website on multiple instances.

Windows Azure makes it cheap if you don’t have much traffic(Shared instance) and easy to scale when you start growing and start to become big(multiple Reserved instances). What more do you need?


Published at

Originally posted at

ASP.NET MVC 4 bundles organization strategy

Lately I’ve been using ASP.NET MVC 4 on a couple of projects and I noticed I began having trouble organizing my JavaScript files properly. The reason being that a default MVC 4 web application comes with the default bundling strategy looking like this:


Now, when you see the default bundles organized by-library, your first thought is – “that’s default behavior, so it’s probably the one I should use ” and you jut go with the flow with it.

Sadly that leads to making a bundle for each library and calling @Scripts.Render method for each library that you’re using on the page. Which leads to this in production:


And if you have your own JavaScript files or add custom libraries, the list could go long pretty fast.

I think bundling should be able to combine all your files into one so we get the best possible optimization. A way of doing that is to make a bundle for each page you’re using with the necessary libraries in it.

If we do this however with the current structure of bundles in MVC 4, we wouldn’t be able to use a CDN for jQuery and the other of the common used libraries, because the CDN is declared on per-bundle basis.

A better approach would be to use different bundles for just the common libraries – jQuery, jQuery UI, Twitter Bootstrap etc. with CDN configurations. And for the custom libraries we could use a bundle for each screen with the custom libraries that each screen uses. So in your base _Layout file we could say:


And in each page we make the include:


Where bundles/index is a custom bundle definition for the Index.cshtml page, where you define all the custom libraries needed for the Index.cshtml page. The bundle definition could look like that:


That way we get both CDN support with the common libraries as well as the most effective and optimized bundle management for the custom libraries and files that change more frequently.  Win-win situation. Or almost.

The downside of this approach is that if you want to put your libraries in your personal CDN, this method of organizing bundles wouldn’t be very effective, I guess, as you’d have to make a different file in the CDN for each bundle e.g. for each page.

However if you’re not planning on using a personal CDN, this approach of bundle organization could save you a lot of confusion with dealing with all the custom JavaScript libraries and scripts you use in your pages.


Published at

Originally posted at