# Tuesday, September 22, 2015

A few weeks ago, Seth Juarez of Channel 9 invited me to be his guest for an interview. We talked about Microsoft's support for open source software and Azure's support of non-Microsoft technologies. You can view this interview below.

Azure | Channel9 | OSS | Video
Tuesday, September 22, 2015 1:09:00 PM (GMT Daylight Time, UTC+01:00)
# Monday, September 21, 2015
Monday, September 21, 2015 1:02:31 PM (GMT Daylight Time, UTC+01:00)
# Tuesday, September 15, 2015

Recently, I interviewed technologist Andy Abbott about his startup BookdeOut, the technologies involved, and how he and his team leveraged the cloud to build the application.


Tuesday, September 15, 2015 11:18:00 AM (GMT Daylight Time, UTC+01:00)
# Monday, September 14, 2015
Monday, September 14, 2015 11:08:54 PM (GMT Daylight Time, UTC+01:00)
# Friday, September 11, 2015

At That Conference last month, Jason and Carl of the MS Dev Show set up a small recording studio in the middle of a hallway and interviewed speakers, organizers, and interesting people. I was fortunate to be included in this list. The show is below and my part is at the end

Friday, September 11, 2015 2:53:17 PM (GMT Daylight Time, UTC+01:00)
# Thursday, September 10, 2015

Azure storage includes built-in redundancy by default. In this screencast, I explain the Replication options that allow you to configure how many copies of your data are created, where they are created, and how they can be accessed.

Azure | GCast | Video
Thursday, September 10, 2015 2:02:42 PM (GMT Daylight Time, UTC+01:00)
# Tuesday, September 8, 2015

Recently, I sat down with my old friend Manohar Kamath to talk about his new startup – Pursuits. Manohar describes Pursuits as a CRM for career transitions because it helps graduating students and other job seekers manage their job search.

He talks about the startup process, his choice of platform (Pursuits is built on Azure) and how BizSpark helped.

You can view and listen to the entire interview below or at this link.

Tuesday, September 8, 2015 3:35:26 PM (GMT Daylight Time, UTC+01:00)
# Monday, September 7, 2015
Monday, September 7, 2015 4:20:00 PM (GMT Daylight Time, UTC+01:00)
# Sunday, September 6, 2015

Today I am grateful for an afternoon yesterday at the Chicago History Museum.

Today I am grateful for my first visit to Waldo Stadium in Kalamazoo and for a Spartan victory last night! ‪#‎GoGreen

Today I am grateful that I get to spend so much time with passionate developers and entrepreneurs.

Today I am grateful for the pleasure and privilege of raising of my son Tim, who turns 21 today.

Today I am grateful to the Azure support team, who fixed my web site, even though it was totally my fault.

Today I am grateful that my cousin Sharon is cancer-free and her ovarian cancer is in remission following 3 months of chemo and radiation treatments.

Today I am grateful for a minor league baseball game last night.

Today I am grateful that my custom Illinois license plate finally arrived after months of delays.

Today I am grateful to all the Purdue students who came out to yesterday's Microsoft event.

Today I am grateful to be able to ride my bike to work.

Today I am grateful that my bike is repaired and fit to ride for the first time in years.

Today I am grateful I got my Angular Service demo working yesterday.

Today I am grateful that, for the first time in over a decade, I am living in a place of my own choosing.

Today I am grateful that, although I lost money on my house sale, I did not have to bring a check to the closing to cover any of the mortgage principle, as some folks in Michigan have done.

Today I am grateful for a day in East Lansing and an evening with the local user group communities.

Today I am grateful for an excellent evening with the Great Lakes Area .NET User Group - one of my favourite tech communities. Missed you guys! It's been too long. #MIGANG http://migang.org/

Today I am grateful to spend a few hours with my mother in her new home last night.

Today I am grateful for: 1. Selling my house yesterday 2. Dinner with Michele 3. Patrick providing me a place to stay last night.

Today I am grateful for 11+ years in this house.

Today I am grateful for coffee in Minnesota with Derek yesterday.

Today I am grateful for: 1. My first game at Target Field 2. Speaking for the first time at #MidwestJS.

Today I am grateful to Sarah, Brian, Brian, Paul, and David, who made me look good with all their hard work at #ThatConference this week.

Today I am grateful to those that work so hard and make #ThatConference great every year.

Today I am grateful for so many good conversations yesterday.

Today I am grateful for a busy, hectic, crazy, productive, successful first day at #ThatConference.

Today I am grateful for seeing so many old friends yesterday.

Today I am grateful for all I've learned about AngularJS this past week.

Today I am grateful for my son's new job offer.

Today I am grateful for: 1. Lunch with Manohar yesterday 2. A good crowd for my presentation last night at the .NET meetup.

Today I am grateful that nearly all of my possessions are now in Chicago.

Today I am grateful to Ondrej, who drove over 600 miles yesterday to help me move.

Today I am grateful for all the things I sold, gave away, and threw away the past few days.

Today I am grateful for dinner in Dexter last night with my sons, Nick's girlfriend, and her parents, who I met for the first time.

Sunday, September 6, 2015 4:17:38 PM (GMT Daylight Time, UTC+01:00)
# Wednesday, September 2, 2015

One of the nice things about Azure storage is that Azure always makes extra copies of your data. How and where those copies are made is up to you.

In the current Azure portal, you select the REPLICATION property of a new Storage Account; In the Azure Preview Portal, you select the Storage Account Type.

In both cases, the options are:

  • Locally Redundant
  • Geo-Redundant
  • Read-Access Geo-Redundant
  • Zone Redundant

Here is an explanation of each type:

Locally Redundant

Three copies of your storage data are created - all within the same region. No two copies will reside in the same Fault Domain and no two copies will reside in the same Upgrade domain.

This provides fault tolerance in case of the failure of one of the machines on which a copy of the storage account is stored. If the entire data center goes down, no copies of your data will be available.

This is the cheapest of the available redundancy options.


As with Locally Redundant storage, Geo-Redundant storage also creates 3 copies of your data on separate fault domains and update domains in the same data center. But it also creates 3 more copies of your data in another region - typically the region nearest the primary region for this account. For example, if you select North Central US as your storage account's primary region, the account data will be replicated in the South Central US Region.

Once this cross-region replication occurs, you are protected from data loss, even if an entire Azure region fails.

Read-Access Geo-Redundant

Read-Access Geo-Redundant storage is identical to Geo-Redundant storage, but it also provides read access to data stored in the secondary region,

Zone Redundant

Three copies of your storage data are created and stored in at least 2 geographically disparate data centers. These data centers may or may not be in the same Region. This provides fault tolerance, even if an entire data center fails.

Zone Redundant Storage Accounts only support Block Blog storage, so selecting this option will limit the uses of your Storage account.


Data within a region or data center is always distributed across multiple update domains and fault domains to protect against most hardware failures or planned maintenance downtime.

Replication within a data center is an atomic operation. In other words, success is not reported to the client until all 3 copies have been successfully written.

Replication to a secondary data center is done asynchronously and typically completes after success has been reported to the client. The good news about this is that clients don't experience any latency when writing to one of a Geo-Redundant storage account. A potential downside is that there is that data in the secondary data center is eventually consistent. If the primary data center fails, it is possible that not all data was written yet to the secondary data center.

Geo-Redundant and Read-Access Geo-Redundant are very similar - both create 6 copies of your data spread across two regions. The difference is that in a Geo-Redundant scenario, the data in the secondary region is only accessible in the event of a failure in the primary region. If all 3 copies of the data in the primary region are unavailable, Azure will fail over to a copy of the data in the secondary region. This also holds true with Read-Access Geo-Redundant, but you get one more benefit: users can access a read-only copy of the data in the secondary region, even if there is no failure in the first region. This can make for greater availability and access speed for users. This also explains why Read-Access Geo-Redundant is the most expensive option. It's the only option that allows users to read copies of the data.

Which Should I choose?

For maximum performance and reliability, Read-Access Geo-Redundant storage is your best option. But this is also the most expensive option. If you are very cost-conscious or if the government requires you to keep data within specific geographic boundaries, you should consider Zone Replication. Geo-Redundant storage is a good compromise between these two options for most scenarios.

Wednesday, September 2, 2015 1:08:06 AM (GMT Daylight Time, UTC+01:00)