Working with Microsoft Azure Resources

On September 22 2014, I had the pleasure of speaking to the MSDEVMTL community about working with Microsoft Azure Resources.

Microsoft Azure Resources include Blob Storage, Table Storage, Queue Storage, Service Bus, Virtual Machines, Cloud Services and SQL Database. During my talk, I introduced a couple of tools that allow us to work with these resources. Some tools are built by Microsoft others are built by companies like Cerebrata, Cloud Berry and Zudio.

Lessons Learned – On #Azure, Log Everything!

Log everything, I mean it! If it wasn’t logged, it never happened.

So you’re probably thinking “doesn’t logging tax an application’s performance?” Absolutely, some logging frameworks can even bring down your application under load. So you really need to be careful about what you log. Therefore, we should log everything that can help us figure out what went horribly wrong. I used the past tense, because on the cloud it’s normal to fail. Never build an application without thinking of Mean Time to Recovery. In other words, how will you recover and how long will it take. Sometimes, when you start on a fresh project, you can only plan for the obvious cases. That means that we have a lot to learn from a brand new application. So in order to facilitate this learning process, I urge you to log anything that can help the DevOps that will get a phone call late at night. Who knows… you might be the one supporting this application.

Take a moment and think about your system. What would you need to know, to be able to identify what went wrong?

Running applications on the cloud without meaningful logs is like flying an airplane without windows or instruments. We know we’re going somewhere… well we think we’re going somewhere. But really where are we going? Is the engine on? Are we climbing or descending? How high are we?

Are these questions making you uneasy?

Let’s think about our applications, do we really know what’s going on? Sure we have performance counters around CPU, Network, Memory and Disk utilization. But what kind of information does that really provide about our application? Knowing that a Virtual Machine (VM) is running, is like being on an airplane without knowing where we’re going. Having meaningful logs provides us with the insights required to know where we’re going.

Fixing the Microsoft.ApplicationServer.Caching.ConfigStoreException

Today I came across the ConfigStoreException. My Worker Roles were constantly being recycled by Windows Azure and I wasn’t able to use the remote debugger to get at any information. (Using Windows Azure SDK 2.2)

To be fair, the Worker Roles ran fine on my local Windows Azure Emulator. As you can imagine, I was completely baffled by all this… So I decided to check if Windows Azure Diagnostics was able to log anything. Fortunately, I was able to get two exceptions. (The exceptions were found in the WADWindowsEventLogsTable located in the Windows Azure Storage Account used for your Windows Azure Diagnostics)

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)

Include a Readable Copy of The Original Queue Message Along With The Stack Trace in The Diagnostics

This is a lesson that took me a while to learn: Providing your team with as much information as possible will help you save time and money.

Debugging a distributed system that uses Windows Azure Queue Storage Service to communicate commands between compute nodes and services can be challenging. It can look like magic! And it can scare the best of your team’s wizards!

Most of the time, the biggest difficulty I run into when creating this kind of service is traceability. Where should events be logged, what events should be logged and what kind of logging mechanism should be use? These are a few questions that need to be answered early on in the applications’ life cycle.

Once these questions are answered, it’s absolutely crucial that everyone on the team is aware of what goes into diagnostics and how they’re persisted. Without this knowledge, team members will not know what to make of the collected diagnostics. Furthermore, the diagnostics will not serve their intended purpose.

Windows Azure Web Sites From Skeptical to Believer

When Microsoft announced Windows Azure Web Sites I was lucky to rapidly gain access to the preview, which led me to write a preliminary Windows Azure Web Sites Review.

Initially I was confused about the ideas behind Windows Azure Web Sites, because Cloud Services give me a finer grain control over various aspects of the Instances. Cloud Services also provide Production and Staging environments, which are not available in Windows Azure Web Sites. To top it off, Windows Azure Web Sites lack Remote Desktop connectivity. I must admit that in the beginning, I had a hard time finding reasons to choose Windows Azure Web Sites over Cloud Services (PaaS).

Windows Azure Web Sites, started off as being perfect for deployments that didn’t require custom windows configurations and were perfect for teams who don’t use Visual Studio. By greatly abstracting away the concept of Roles, it opened up the platform to a greater audience and most importantly Windows Azure Web Sites consume  other Windows Azure services like Windows Azure Storage Services.

Almost a year later, Windows Azure Web Sites has grown up and above all, I am now a true believer!  In June 2013,  Standard (formerly named reserved) and Free tiers have both graduated from Preview to General Availability (GA)  and are backed by the standard 99.9% monthly SLA. The Shared tier remains in preview with not charges.

Windows Azure Web Sites have come a long way!