Geeks With Blogs
Ryan Abrahamson

At Industrack,we migrated our production backend to Azure. Our platform is a real-time data collection system of GPS data streaming from remote devices. For the most part it is working well, there are some gaps in services that I am expecting from Azure that hard are hard to find from external vendors. Microsoft has a 99.9% SLA on their Azure services that covers Maintenance windows an transient errors as well that arise from load throttling other intermittent connection failures.

I have notices that since Microsoft has been trying to get so much out into the hands of developers lately that they are sacrificing some of their historical consistency. For example, we decided to upgrade our Enterprise Library from 4.1 to 5.0. Ent Lib 6.0 was not an option for us at this point as we had dependencies on shard libs that have to work on Windows XP. Ent Lib 6.0 is compiled with .NET 4.5, which is not supported on Windows XP. That said, I ended up having to recompile the Azure TransientFaultHandling Block locally anyway as it had dependencies on an earlier version of the Azure SDK that I was using.

For those that are using any Azure services, you should be using the TransientFaultHandling block for handling retries to the service. It has some nice classes for allowing you to define different retry strategies.

SQL Azure has been working well, although we ran in to an instance where we ran our of space in the tier of database that we had (5GB) and we lost 2 hours of data before we noticed that connections were failing with an exception that described the problem, however, it seems like the admin on the Azure account SHOULD have received a notification of the condition so it could be resolved. It is an easy fix, go to the admin screen and pick the next tier of SQL and click save! But some notification here would have saved me some big headaches.

We are using the Service Bus to consolidate the data from the different endpoints we support which has also been working well. However, I recommend spending time learning about Prefetch, Deadlettering, and PeekLock to use the queues in an efficient manner

We are just starting to use SQL Reporting in Azure and so far this looks promising. If you do have a current installation of SSRS that you are thinking of migrating, make sure you look at the list of things NOT supported in SSRS for Azure to make sure you are aware of all the things in your current reports that might not work as well as scheduling and delivery.

So far my only real disappointment is in the Azure VM area. so far this has proven very unreliable with the VMs restarting unannounced on the order of 1 time per week or so. I have no idea why it restarts, but from what I have read it can happen due to hardware failures and the platform moving the VM to different hardware and restarting it. but again, with NO NOTIFICATION! We cannot manage something that does not alert us when actions like this are being taken.

In general the whole Monitoring area of Azure is missing. When you consider the tools that Microsoft has for monitoring, System Center, and the capabilities it brings to table, the fact that these features are missing from Azure is really disappointing. If that kind of monitoring was available out of the box, Azure would truly be a Word Class platform differentiating itself from Amazon, Google, etc.

Posted on Sunday, May 19, 2013 9:27 AM | Back to top


Comments on this post: Things to Watch out for with a Production system in Microsoft Azure

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © ryanabr | Powered by: GeeksWithBlogs.net