Tag Archives: maps

Stupid Azure Trick #5 – Got a Penny? Run a Simple Web Site 100% on Blob Storage for a Month – Cost Analysis Provided

Suppose you have a simple static web site you want to publish, but your budget is small. You could do this with Windows Azure Storage as a set of blobs. The “simple static” qualifier rules out ASP.NET and PHP and Node.js – and anything that does server-side processing before serving up a page. But that still leaves a lot of scenarios – and does not preclude the site from being interactive or loading external data using AJAX and behaving like it is dynamic. This one does.

Check out the web site at http://azuremap.blob.core.windows.net/apps/bingmap-geojson-display.html.


You may recognize the map from an earlier post that showed how one could visualize Windows Azure Data Center Regions on a map. It should look familiar because this web site uses the exact same underlying GeoJSON data used earlier, except this time the map implementation is completely different. This version has JavaScript code that loads and parses the raw GeoJSON data and renders it dynamically by populating a Bing Maps viewer control (which is also in JavaScript).

But the neat part is there’s only JavaScript behind the scenes. All of the site’s assets are loaded directly from Windows Azure Blob Storage (plus Bing Maps control from an external location).

Here’s the simple breakdown. There is the main HTML page (the URL specifies that directly), and that in turn loads the following four JavaScript files:

  1. http://ecn.dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=7.0 – version 7.0 of the Bing Map control
  2. httpGetString.js – general purposes data fetcher (used to pull in the GeoJSON data)
  3. geojson-parse.js – application-specific to parse the GeoJSON data
  4. bingmap-geojson-display.js – application-specific logic to put elements from the GeoJSON file onto the Bing Map

I have not tried this to prove the point, but I think that to render on, say, Google Maps, the only JavaScript that would need to change would be bingmap-geojson-display.js (presumably replaced by googlemap-geojson-display.js).

Notice that the GeoJSON data lives in a different Blob Storage Container here:  http://azuremap.blob.core.windows.net/maps/azuremap.geojson. We’ll get into the details in another post, but in order for this to work – in order for …/apps/bingmap-geojson.html to directly load a JSON data file from …/maps/azuremap.geojson – we enabled CORS for the Blob Service within the host Windows Azure Storage account.

Costs Analysis

Hosting a very low-cost (and low-complexity) web site as a few blobs is really handy. It is very scalable and robust. Blob Storage costs come from three sources:

  1. cost of data at rest – for this scenario, probably Blob Blobs and Locally Redundant Storage would be appropriate, and the cost there is $0.068 per GB / month (details)
  2. storage transactions – $0.005 per 100,000 transactions (details – same as above link, but look lower on the page) – where a storage transaction is (loosely speaking) a file read or write operation
  3. outbound data transfers (data leaving the data center) – first 5 GB / month is free, then there’s a per GB cost (details)

The azuremap web site shown earlier weighs in at under 18 KB and is spread across 5 files (1 .html, 3 .js, 1 .geojson). If we assume a healthy 1000 hits a day on our site, here’s the math.

  • We have around 1000 x 31 = 31,000 visits per month.
  • Cost of data at rest would be 18 KB x $0.068 / GB = effectively $0. Since storage starts at less than 7 cents per GB and our data is 5 orders of magnitude smaller, the cost is too small to meaningfully measure.
  • Storage transactions would be 31,000 x 5 (one per file in our case) x $0.005 / 100,000 = $0.00775, or a little more than 3/4 of a penny in US currency per month, around 9 cents per year, or $1 every 11 years.
  • Outbound data transfer total would be 31,000 x 18 KB = 560 MB, which is around 1/10th of the amount allowed for free, so there’d be no charge for that.

So our monthly bill would be for less than 1 penny (less than US$0.01).

This is also a good (though very simple) example of the sort of cost analysis you will need to do when understanding what it takes to create cloud applications or migrate from on-premises to the cloud. The Windows Azure Calculator and information on lower-cost commitment plans may also prove handy.

Alternative Approaches

Of course in this day and age, for a low-cost simple site it is hard to beat Windows Azure Web Sites. There’s an entirely free tier there (details) – allowing you to save yourself nearly a penny every month. That’s pretty good since Benjamin Franklin, one of America’s founding fathers, famously quipped A penny saved is a penny earned!.BenFranklinDuplessis.jpg

Windows Azure Web Sites also has other features – your site can be in PHP or ASP.NET or Node.js or Python. And you can get continuous deployment from GitHub or Bitbucket or TFS or Dropbox or others. And you get monitoring and other features from the portal. And more.

But at least you know you can host in blob storage if you like.

[This is part of a series of posts on #StupidAzureTricks, explained here.]


Where’s Azure? Mapping Windows Azure 4 years after full General Availability.

On October 27, 2008, Windows Azure was unveiled publicly by Microsoft Chief Architect Ray Ozzie at Microsoft’s Professional imageDeveloper’s Conference.

Less than a year later, on November 17, 2009, Windows Azure was unleashed on the world – anyone could go create an account.


Only a couple of months later, on January 1, 2010, Windows Azure turned on its Service Level Agreement (SLA) – you could now get production support.

And finally, on Feb 1, 2010, Windows Azure became self-aware – billing was turned on, completing the last step in them being fully open as a business.

That was 4 years ago today. Happy Anniversary Azure! I am not calling this a “birthday” since it isn’t – it was born years earlier as the Red Dog project – but this is the fourth anniversary of it being a fully-operational, pay-as-you-go, public cloud platform.

At the time, there were 6 Windows Azure data centers available – 2 each in Asia, Europe, and North America: East Asia, SE Asia, North Europe, West Europe, North Central US, South Central US. (Ignoring the Content Delivery Network (CDN) nodes which I plan to cover another time.)

What about today? With the addition in 2012 of East US and West US data centers, today there are 8 total production data centers, but more on the way.

Here’s a map of the Windows Azure data center landscape. (Source data is in a JSON file in GitHub; pull requests with additions/corrections welcome. CDN data is TBD.)

The lines between data center regions represent failover relationships drawn from published geo-replication sites for Windows Azure Storage. Mostly they are bi-directional, except for Brazil which is one-directional; the metadata on each pushpin specifies its failover region explicitly.

NOTE: this is a work-in-progress that will be updated as “official” names are published for geos and regions.

Also, be sure to click on the map pushpins to see which data center regions are in production and where are coming attractions. Not all of these pushpins represent data centers you can access right now.

There are three insets in order – first a GeoJSON rendering, second a TopoJSON rendering (which should look identical to the GeoJSON one, but included for demonstration purposes, as it is lighter weight), and the third is the raw JSON data from which I am generating the GeoJSON and TopoJSON files. [All the code is here: https://github.com/codingoutloud/azuremap. I plan to blog in the future on how it works.]

Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
{ "Geo" : "Asia Pacific", "Region": "Asia Pacific East", "Location": "Hong Kong", "Failover Region" : "Asia Pacific Southeast", "Status" : "Production" },
{ "Geo" : "Asia Pacific", "Region": "Asia Pacific Southeast", "Location": "Singapore", "Failover Region" : "Asia Pacific East", "Status" : "Production" },
{ "Geo" : "Asia Pacific", "Region": "Shanghai China", "Location": "Shanghai China", "Failover Region" : "Beijing China", "Status" : "Production" },
{ "Geo" : "Asia Pacific", "Region": "Beijing China", "Location": "Beijing, China", "Failover Region" : "Shanghai China", "Status" : "Production" },
{ "Geo" : "Australia", "Region": "Australia East", "Location": "Sydney, New South Wales, Australia", "Failover Region" : "Australia SE", "Status" : "Production" },
{ "Geo" : "Australia", "Region": "Australia SE", "Location": "Melbourne, Victoria, Australia", "Failover Region" : "Australia East", "Status" : "Production" },
{ "Geo" : "South America", "Region": "Brazil South", "Location": "Brazil", "Failover Region" : "US South Central", "Status" : "Production" },
{ "Geo" : "Europe", "Region": "Europe West", "Location": "Amsterdam, Netherlands", "Failover Region" : "Europe North", "Status" : "Production" },
{ "Geo" : "Europe", "Region": "Europe North", "Location": "Dublin, Ireland", "Failover Region" : "Europe West", "Status" : "Production" },
{ "Geo" : "Japan", "Region": "Japan East", "Location": "Saitama, Japan", "Failover Region" : "Japan West", "Status" : "Production" },
{ "Geo" : "Japan", "Region": "Japan West", "Location": "Osaka, Japan", "Failover Region" : "Japan East", "Status" : "Production" },
{ "Geo" : "United States", "Region": "US North Central", "Location": "Chicago, IL, USA", "Failover Region" : "US South Central", "Status" : "Production" },
{ "Geo" : "United States", "Region": "US North Central", "Location": "Chicago, IL, USA", "Failover Region" : "US South Central", "Status" : "Production" },
{ "Geo" : "United States", "Region": "US Central", "Location": "Iowa, USA", "Failover Region" : "US East 2", "Status" : "Production" },
{ "Geo" : "United States", "Region": "US East", "Location": "Bristow, Virginia, USA", "Failover Region" : "US West", "Status" : "Production" },
{ "Geo" : "United States", "Region": "US East 2", "Location": "Virginia, USA", "Failover Region" : "US Central", "Status" : "Preview" },
{ "Geo" : "United States", "Region": "US West", "Location": "San Francisco, California, USA", "Failover Region" : "US East", "Status" : "Production" },
{ "Geo" : "United States", "Region": "US Gov-Iowa", "Location": "Iowa, USA", "Failover Region" : "US Gov-Virginia", "Status" : "Preview" },
{ "Geo" : "United States", "Region": "US Gov-Virginia", "Location": "Virginia, USA", "Failover Region" : "US Gov-Iowa", "Status" : "Production" }

The map data is derived from public (news releases and blog posts for coming data centers and Windows Azure documentation for existing production regions).

The city information for data centers is not always published, so what I’m using is a mix of data directly published, and information derived from published data. For example, it is well known there is a data center in Dublin, Ireland, but where city should I used for US West region that’s in California? For the latter, I used IP address geocoding of the published data center IP address ranges. This is absolutely not definitive, but just makes for a slightly nicer map. It was from this data that I made assumptions around Tokyo and Osaka locations in Japan and San Francisco in California for US West.

Finally, this map is at the region level which equates roughly to a city (see the project readme for terminology I am using). A region is not necessarily a single location, since there may well be multiple data centers per region and though they will be “near” each other, this is not necessarily in the same city – they could be 1 kilometer apart with a city border between them.