I’m making this post to show how I utilize the Azure message bus in order to achieve scalability and availability for tellmon.net. You can view a small presentation below.
I use the message bus to publish device and sensor changes both internally inside a single tellmon instance, but also between multiple instances when Azure auto-scales on high load.
Data arrives from Telldus via HTTP post requests. They are then stored in Azure SQL and published to the message bus.
Inside each tellmon.net instance is a signalR hub that has a separate subscription to the topic ensuring that each instance gets a copy of every message. The signalR hub checks incoming messages and if it has a client (browser) connected that “owns” the incoming sensor/device it will forward the new state via signalR. On the client the incoming signalR message updates the view model that in turn updates the UI via knockout JS databinding.
In addition each tellmon.net instance has an Alarm handler running as a WebJob. Where each signalR hub has it’s own subscription to ensure they get all messages the WebJob alarm handlers share a single subscription. Thus each message is only handled by one alarm handler instance. Which one is irrelevant as they all to the same job. They check the sensor value against defined alarm limits and sends the user an email if the new value was outside the set limit.
This architecture work equally well whether tellmon.net is a single instance or it’s scaled out by Azure to multiple instances.
The trick is that each new instance must create it’s own subscription to the message bus topic. You can use the environment variables WEBSITE_INSTANCE_ID and WEBSITE_SITE_NAME to create a unique subscription name.
Environment.GetEnvironmentVariable("WEBSITE_INSTANCE_ID");
Environment.GetEnvironmentVariable("WEBSITE_SITE_NAME");Then I remove the subscription again in the Application_End event. To make sure a “stale” subscription is not left if something crashes and your Application_End event is not fired I make sure to specify that the subscriptions are to be deleted on idle.
var description = new SubscriptionDescription(topicPath, subscriptionId);
description.AutoDeleteOnIdle = TimeSpan.FromSeconds(600);
namespaceManager.CreateSubscription(description);
The beauty of this design is that you can use the exact same architecture on-premise using the Windows Server Message Bus. Also debugging by starting up a local instance from Visual Studio is also a breeze since it has access to both the Azure SQL and the Azure message bus making your local instance just another instance in the cluster (expect you won’t get hit by external users).
