Initial Azure Impressions
For about the last month I’ve had the opportunity to work on a couple of different projects that heavily use Microsoft Azure. This is my first significant exposure to Azure and its services and over this last month I’ve experienced both the good and the bad. I wanted to share some of my insights, not as an expert but instead as a developer who is still heading up the learning curve.
The Good
The Tools
The tools available within Azure are amazing. Just about anything you need is in Azure. Setup SQL databases, cache, storage, and much more with ease. Amongst this plethora of tools, there are a few standout services I used.
Service Bus
“Addictive” is one way to describe the service bus. Many applications can benefit architecturally from a system of queues and topics. For all of those fire-and-forget threads you want to run, put ‘em on a queue and let another process handle it. If you need a fancy pub/sub system, you can use topics for that. It is wonderful how easily these advanced systems make moving messages around your system (and other systems).
WebJobs
Event-driven tasks work great as WebJobs. You create a simple console program and Azure will run it for you. From a simple scheduled event to new messages arriving on a service bus queue, WebJobs can handle a wide variety of events that happen within Azure.
Logic Apps
Logic Apps are workflows with no code at all. While they will not replace code every time, they are great for common work that many applications do.
Need to send an email when a file is received? Logic App.
Need to FTP a file when a new message is put onto a queue? Logic App.
Need to watch for certain Tweets, translate them to Italian, save them in Dropbox, store them in an Azure SQL table, and then email them to your boss? Logic App.
The Deployment
Getting new/updated items deployed into Azure is a breeze. Right-click-and-deploy just works. We also were able to set up continuous integration in Azure via TeamCity and Octopus. Now we don’t even think about the deployment.
The Bad
Tooling
The tools for setup, configuration, and maintenance of Azure are terrible. Microsoft wants you to use their “new portal” for all of your Azure setup needs. Except some things, like service bus, need to be configured in the “classic” portal with its own look and feel. Oh, and of course some setup cannot be done in either UI portal and must be done via an external tool like Visual Studio or PowerShell.
Whether or not it is true, I’ve envisioned a system at Microsoft where the Azure team comes up with a great new service and immediately deploys it into production. Then one poor guy sitting in a dark room somewhere discovers this deployment and has to hack together a way to configure and maintain the new service. And this guy is way behind the team working on the slick new services!
Frequent Changes
Frequent changes are not necessarily a bad thing. In fact, it is a sign of a healthy and evolving ecosystem. However, more than once I’ve tried using a component and ran into problems, and then had difficulty finding the answers that I needed because it is either brand new or updated.
Microsoft does have several “Getting Started” articles for much of what is available and these seem to be largely up to date. The articles help get your feet wet and point you in roughly the correct direction. However, as soon as you need to venture into anything beyond the trivial, these often times leave out key information and finding what you need can be a struggle.
Cannot Set Up Stand-Alone Dev Environments
I want to be able to test my changes entirely locally and without affecting other developers or testers. However, Azure makes it so that some of what I’m doing has to be done in Azure, which could impact others.
There are some emulators that help with this and could allow you to run locally. However, there are no emulators for Service Bus queues and triggers, forcing our development team to implement some hacks to avoid stepping on each other.
Other times, even when there are emulators, they don’t work for all Azure functions (I’m looking at you, Storage Emulator with WebJobs). We have hacked and slashed our way around some of these issues but we have not completely isolated our developers from each other.
Configuration
Connection string overload! So many connections! Trying to manage these is a headache. We have our CI tools that help a lot but getting those set up takes effort away from solving our business problems. When coupled with some of our hacks to isolate ourselves from the other developers, there is even more configuration floating around.
Also, when using cloud services, your web.config cannot be changed without redeployment. If you need runtime configuration for some settings, you have to configure this in Azure and then write more code to use those settings as needed.
Diagnostics
Finding issues can be difficult. It does take some thought to get a solution in place that will generate the diagnostic information that you need. This is not necessarily unique to Azure but the implementation may be a bit different from what you are used to.
The several-minute delay between when something happens and when you will get access to the diagnostic traces for review is also rough on productivity.
Overall
Azure gets my recommendation. I would encourage other developers to use it if it seems like the project is a fit. The wide variety of tools available are very valuable.
Be forewarned however that Azure isn’t without its headaches. StackOverflow will quickly become an even dearer friend. Just don’t get discouraged by the learning curve.
Photo credit: Horia Varlan via Flickr cc
