I am extremely fond of Microsoft’s cloud infrastructure offering. I am hosting my current project, my blog sites (including this blog), and several test sites and projects in Azure and I have been really impressed with it. For my project, I am using an Azure website for my user interface, an Azure virtual machine for my background processing, Azure Storage Queues (as a transport for NServiceBus), Blob Storage, and Azure SQL databases. There was a learning curve for dealing with Azure Storage Queues and their limitations and learning how they are different from MSMQ. Azure SQL has some differences and limitations that need to be considered in comparison to managing your own SQL Server. Azure websites need some care and thought to get them to perform properly and I’ve found that the startup on the first request to a site that hasn’t been getting use and without a live and running IIS worker process takes a long time, though there is a built-in feature in Azure that keeps the site running. Other than these and some other growing pains, I have found the experience in working with Azure to be extremely pleasing.
I have used Amazon AWS for hosting applications before and I find their offering to be exceptional and excellent as well. I thought I would wind up hosting my current project there, but with Microsoft giving BizSpark program participants $150/month in Azure credits, it seemed I needed to at least consider using Azure. I have also used Digital Ocean for some test sites and projects and I like it as well, primarily for pricing, as well as performance. It’s a good choice for projects that don’t benefit from using Windows Servers. Choosing to use NServiceBus means I am choosing to use .NET. This doesn’t have to mean using Windows, but it’s a shorter path to just go with Windows than dealing with the limitations of Mono. Also, I like Linux, but I’m more familiar and comfortable with Windows and it’s an easier maintenance story for me. In addition, NServiceBus has support for using either Azure Storage Queues or Azure Service Bus as transports. This seemed more appealing than needing to manage and/or implement my own transport in AWS or forgo NServiceBus and implement prevention of data loss, durable messaging, and workflow in some other way. It turned out that using Azure was a good choice for reasons beyond just the cost benefit from BizSpark.
Azure Websites – Just plain easy
The best thing about using Azure Websites is that you can easily create a site and deploy to it directly from Visual Studio via downloading a publishing profile from the Azure portal, or even better: hook it to your source control for continuous deployment. That continuous deployment is this easy and doesn’t require tons of scripting and infrastructure setup is a HUGE win. I am in love with Azure Websites for this alone. It’s really exciting that this works as well as it does and is as easy to set up as this. Beyond setup and deployment, using a website means there’s no need to worry about setting up and configuring the IIS webserver, creating sites and applications, patching the operating system or IIS, or any of that stuff. It’s also easy to configure the site to auto-scale with lots of options for types and numbers of machines and when to add and remove capacity. There is also a glut of images useful for creating sites using well-known web applications and frameworks, like WordPress, Drupal, Orachard CMS, and many other usual suspects. Using custom domains and SSL certificates is easy as well. In addition, for test sites and playing around or something where marketing/branding is not important, you can just use a subdomain under azurewebsites.net and away you go with a website available on the public internet.
Virtual Machines – Flexible infrastructure on demand
Virtual machines are exactly what I expected them to be – machines you can use to do whatever you need to do. Configuring access to ports with IP filtering is easy in the Azure portal, which is expected. There are a few things that surprised me, though. The first is how easy it is to beef up a machine that is under-provisioned for the workflow for which it is being used. I have a machine running my background processing doing some moderately CPU and memory intensive processing in bursts. Transcoding and compressing audio and video is the primary offender here. When I determined my machine was underpowered, I thought I would wind up doing what I have done in the same situation before in AWS – create an image of the machine, wait for the image to complete, create a new instance using the new image, wait for the new machine to come online and become available, transfer execution and references to the new machine, and shut down the old. To my shock and elation, I went into the Azure portal and just changed the pricing tier of the machine and saved the change. I was warned that the machine would have to restart. It did, without my having to do anything further. It came back up with more memory and 2 cores instead of one and handled my workload much better. This could not have been any easier and I was very impressed with what the Azure offering provided. Also wonderful (and at first shocking), you are not limited to Windows with Azure Virtual Machines. This is an exciting development from the new Microsoft that is very much the opposite of the old Evil Empire. This is not your daddy’s Redmond dynasty.
SQL Azure – Limitations dying every day
When I first started using SQL Azure, I found that the database engine itself was adequate for my needs and I was happy with being able to remotely access and administer my databases via Management Studio on my machine, but I was a little dismayed at some of the limitations of the capabilities of what I could do in the Management Studio client. It turns out that SQL Azure is not a full implementation of SQL Server hosted in Azure as I expected, but a different database engine that implements most of the protocol defined by SQL Server. This has meant that there are things I have done with SQL Server that I just can’t do with SQL Azure. First, a limitation that remains to this day is that I can’t use a using statement to select the database for which I am issuing statements. As a productivity junkie obsessed with keyboard use, this presented a problem. In addition, I also noticed early on that in a query Window in Management Studio, that after executing a query against a database, I could not switch to another database. This meant that the Ctrl-U combination for selecting a database from the dropdown in Management Studio works, but not as ideally as I would hope. It also meant that a mistaken execution against the Master database couldn’t be corrected without closing the query window and opening a new one. This was not disastrous, but frustrating.
It has been beautiful and exciting working with Azure, especially SQL Azure over the last few months and seeing it mature. Query Windows can now be switched to other databases on an Azure SQL Server instance with Ctrl+U without having to move to a new window. I have even seen it autocomplete the database selection dropdown after keying the first few characters of a database name (though I can’t make it do this consistently and haven’t figured out what magical conditions make it happen). The short version of what I am saying is that Microsoft is dedicated to make Azure better, and under the direction of Scott Guthrie, it is getting better every day and is a joy to use.