Ok, that’s it, I’m started for feature requests on Windows Azure with my last Blog Entry, let’s keep going!
I’ve spoke about how Azure Storage, and more specifically Azure Tables, lack querying capabilities. Another Azure Storage component, Azure Queues, also lack a big feature: notification!
To some extent Azure queues are even less optional than Azure tables. They are the best communication mechanism between different roles. The architecture is quite elegant and simple. Removing ACID transactions from the picture of course helped lot in simplifying the architecture (look at how SQL Server Broker Services handles poison messages for instance).
Queues have always been a great communication mechanism within distributed architecture and not considered enough within the Microsoft community to my opinion.
Now, as I said, a big feature that Azure Queues are lacking is notification. The only model we have to access a queue is probing: ask the queue if it has any messages. Now that’s ok if you have an ad hoc application starting and wondering if it got mail. But for a background process (ie Worker Role) processing messages from a queue, that means probing the queue continuously. This approach has many shortfalls:
- Each time you probe an Azure Queue, you’re charged for it. It’s very cheap, but if you probe the queue multiple times a seconds, charges adds up.
- You can actually overflow the queue with queries, in which case it will return error messages to back you off.
- If you want to avoid that, you can implement some logic in your code where you probe often, then when there’s nothing, you back off exponentially. The issue with this approach is that when a message finally comes in, you’ll pick it up late.
- Your worker role is spinning and consuming CPU just to make sure the queue is empty.
Of course, a good solution to those problems is notification: have your worker role enlist to a notification engine that will call it when a message comes in. There are no notification engine currently.
Now if you step back a little and think about it, you can generalize this solution and it would solve many problems. The general solution would be to have an Azure event bus and have different components optionally publishing or listening to it. For instance, you might want to take some action when an Azure Table or an Azure Blob is modified (sort of a clean trigger), when an SQL Azure schema is modified, when a role is taken offline or another is brought online, etc. .
Of course, as usual, this isn’t trivial in the could. You would need this event bus to be distributed in order to be reliable, but mostly, you would need to fix the usual problems of notifications. For instance, what does the notification engine do if it can’t reach my role? Does it retry, does it un-enlist my role from the notification? Should we support notification clients outside Windows Azure walls?
Well, actually, a simpler solution would actually to come back to queues. Why not enlist to notifications via a queue you’re monitoring? For instance, you could specify you would like to be notified when something happened to an Azure Table and those notifications would be posted in your queue.
Ah yeah, but we would still need a notification engine for the queue itself then! Well, I think it would be acceptable if would only be supported for roles hosted within Windows Azure and it could be baked in directly into the runtime, so that no TCP or HTTP endpoint would need to be explicitly exposed: the platform would take car of it and raise a .NET event. That solution wouldn’t be non-.NET friendly though, true.
But I know first hand that it would be handy since I have to bake in a notification scheme into an Azure Application I’m architecting right now. This is the type of infrastructure that takes time to build and stabilize and add no direct value to an application. It would be of immense value for Windows Azure to support this feature built-in!