I Take it Back! Use Windows Azure Diagnostics

I used to create my own logging mechanisms for my Windows Azure Cloud Services. For a while this was the perfect solution to my requirements. But It had a down side, it required cleanup routines and a bit of maintenance.

In the recent months I changed my mind about Windows Azure Diagnostics and if you’re not too adventurous and don’t need your logs available every 30 seconds, I strongly recommend using them. They’ve come such a long way since the first versions that I’m now willing to wait the full minute for my application logs to get persisted to table storage.

The issues I had with Windows Azure Diagnostics were because of my ignorance and half because of irritating issues that used to exist.

• I didn’t know how to efficiently read from Windows Azure Diagnostics
• Changing Windows Azure Diagnostics configurations used to mean a new release (code changes and deployment)

Windows Azure SQL Database Automated Backup Frequency is in UTC (Coordinated Universal Time)

The Windows Azure team has recently released Windows Azure SQL Database Automated Backups. Up until yesterday, I was not sure if the FREQUENCY was in Local Time or in UTC (Coordinated Universal Time). I had a hunch that like the Windows Azure SQL Databases, the FREQUENCY could in fact be in UTC (Coordinated Universal Time).

Today I was informed that it’s not adjusted to the browser’s local time and that we need to set the FREQUENCY using UTC (Coordinated Universal Time).

You can view the current UTC time from http://time.is/UTC

Consider Using UTC (Coordinated Universal Time) When Designing REST APIs

With an ecosystem of devices that is constantly evolving, it’s hard to predict who will consume your REST APIs and how they will consume them. Devices as we know them are changing shape, consequently applications are constantly adapting to new platforms.

Lets face it, mobile apps are the norm and shouldn’t be ignored. They travel and shouldn’t be considered as sedentary.

Imagine a scenario where you are on a business trip and try to fetch today’s news from a different continent. Your device formulates a URI with a date and calls a service… no results…
That’s weird! Its 10 PM and I should get results for today’s news. This is probably the moment where you realize that you aren’t in your normal time zone… your phone has adapted to your new geographic location but the APIs the app is calling has not!

Midnight Universal Time is not Midnight Local Time!

A few of my peers have recently move to the cloud and some have found out that we can no longer ignore time zones!

DateTime is an object that is familiar to us. Most of the time we use it without any second thoughts. There lies our first mistake. Not using the DateTimeOffset in code that runs on the cloud can result in some strange and unwanted behavior.

The reason DateTime is usually the reason why our dates are off, is that by default it creates dates in local time. To create a date in UTC you are required to specify a DateTimeKind.Utc in the date’s constructor.

Imagine the following scenario. A developer is executing code in the Windows Azure emulator to debug the code before deploying to the production environment on the cloud. The configurations of the code running in the emulator if pointing to the production database and the code is creating dates using the DateTime object. These dates are then inserted into Windows Azure SQL Database. Then the developer, who is satisfied with the results, goes to production with the new code.

A few days go by, then suddenly a client calls to report weird dates and that the application isn’t working as expected. Tickets are created in the past! A second customer also reports this weird behavior, but he reports that dates are in the future!  Just so we’re clear, time travel is not a possible cause…