I’ve been working with the Azure Service Bus quite a bit lately and have discovered some catches to working with it. These aren’t technology catches, but rather related to the SDK and tooling support surrounding the Azure Service Bus features. Even though Azure Service Bus has been around almost since the beginning, for years, it seems to be neglected a bit by recent tooling updates. This is likely due to the fact that it’s an extremely mature feature set of Azure, but that does create some pitfalls to navigate during development and deployment. In this article, I’ll describe these items I’ve found to help bring clarity to working with the Azure Service Bus.
Azure Service Bus + Azure PowerShell
The Azure PowerShell tools provide support for managing almost all resources in Azure. One area where they are lacking is with Azure Service Bus. You can create an Azure Service Bus Namespaces using PowerShell, but you can’t manage Queues, Topics/Subscriptions, Relays, Event Hubs, etc.
For proof, here’s the Azure PowerShell cmdlet for creating an Azure Service Bus Namespace:
New-AzureSBNamespace -name SuperNamespace -Location North Central US
I have inquired about the lack of Service Bus support within Azure PowerShell, but it seems the Service Bus team at Microsoft isn’t actively working on things currently. It’s good that with Azure PowerShell being Open Source, someone could always contribute this functionality if there were to build it. However, for now you just wont be able to fully manage Azure Service Bus using PowerShell.
Azure Service Bus + Xplat-CLI
The Azure Xplat-CLI provides cross-platform command-line support for managing Microsoft Azure resources. This is also an Open Source project, and it’s features are generally kept synchronized with Azure PowerShell. Unfortunately, this means that the Azure Xplat-CLI is also currently lacking support to fully manage Azure Service Bus resources.
Just as with Azure PowerShell, the Xplat-CLI also allows for the management of Azure Service Bus Namespaces. Here’s the command for creating a new Azure Service Bus Namespace with Azure Xplat-CLI:
azure sb namespace create <namespace> <region>
Azure Service Bus + ARM Templates
Azure ARM Templates are the newest Azure Automation feature for deploying and managing the configuration of Azure resources. Even though it’s much newer than Azure PowerShell and Xplat-CLI, it does actually have better Azure Service Bus support. However, the BIG catch is it’s not documented anywhere. Well, almost nowhere, there are some thing sprinkled about the web about Azure Service Bus and ARM Templates.
While ARM Templates do not currently look to support managing all the features of Azure Service Bus, it’s unclear if this is true. The lack of documentation shrouds Azure Service Bus ARM Template support in mystery. Fortunately, I have been able to aggregate little bits and pieces, along with my own discovery wins, and piece together some examples of deploying Azure Service Bus resources using ARM Templates.
I have contributed my findings to a couple sources, including blog posts as well as contributing ARM Templates to the Azure Quickstart Templates library.
Here’s the list of Azure Quickstart Templates I’ve contributed to the Open Source project for managing / deploying Azure Service Bus resources:
- Create Service Bus Namespace
- Create Service Bus Namespace and Queue
- Create Service Bus Namespace and Topic
- Create Service Bus Topic with Subscription
Also, here’s a couple articles I have published recently as well:
- Azure ARM Template: Create Service Bus Namespace
- Azure ARM Template: Create Service Bus Topic with Subscription
The one current downside with ARM Templates, in addition to the current lack of documentation, is that it doesn’t look to fully support the management / deployment of Azure Service Bus resources. However, I am still working on figuring out more information on ARM Template support and will post more to this blog as I discover / figure more out.
In an effort to continue with the “show the code” theme in this article, here’s the “Create Service Bus Namespace” ARM Template from the Azure Quickstart Templates:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"serviceBusNamespaceName": {
"type": "string",
"metadata": {
"description": "Name of the Service Bus Namespace"
}
}
},
"variables": {
"sbVersion": "2015-08-01"
},
"resources": [
{
"apiVersion": "[variables('sbVersion')]",
"name": "[parameters('serviceBusNamespaceName')]",
"type": "Microsoft.ServiceBus/namespaces",
"location": "[resourceGroup().location]",
"properties": {
},
"resources": [
]
}
],
"outputs": {
}
}
Dual Azure Portals
Currently there are 2 Azure Portals; the Current Azure Portal and the Classic Azure Portal. With the release of what used to be called the Preview Portal to be the Current Azure Portal, you might assume that it supports all Azure features. However, there are a few Azure features that you must go to the Classic Azure Portal for. Azure Service Bus is among them. You can not manage Azure Service Bus resources from within the Current Azure Portal.
Even though the Classic Azure Portal does support the management of all of the Azure Service Bus features, it doesn’t support adding Filters to Service Bus Topic Subscriptions. Filters are a big feature you need to use when implementing Azure Service Bus Topics, since you’ll have multiple message types flowing through the Topic that will need to be caught and handled by different Message receivers. At least you will if you use Service Bus Topics as they’re intended, otherwise Service Bus Queue would be the right tool if you only have a single Message receiver handling all messages. To create and manage Filters on Service Bus Topic Subscriptions, you currently must use the development SDKs (such as the .NET SDK) to write a custom application that manages them for you.
Hopefully some day the Current Azure Portal will get support for ALL Azure features, but for now you’ll need to use the Classic Azure Portal to manage Azure Service Bus resources through a portal experience.
Custom Development SDK’s
The developer SDK’s (.NET and other platforms) support Azure Service Bus just fine when building custom applications. The area where things start to be unsupported is when you need to work with Azure Service Bus from a management and automation perspective. The development SDK’s are where you have full power to manage your Azure Service Bus resources. This is likely due to the fact that the SDK’s were built in a time when they really were the way to interact with Azure services.
When building a custom application you can create and manage all aspects of the Azure Service Bus. This is extremely helpful since it does provide a way to implement automation, even if it is in a procedural fashion and not as Infrastructure as Code (IaC). Using this method of automation, you’ll just have to write small application that will augment your other automation PowerShell or Xplat-CLI scripts, or even ARM Templates.
Conclusion
Hopefully this clarifies the Azure Service Bus SDK and Tooling support a bit. If you haven’t worked with Azure Service Bus yet, maybe this will give you a primer to start with. Otherwise, hopefully this cleared things up if you’ve been a little confused thus far.
With the PowerShell and Xplat-CLI being Open Source, anyone could contribute Service Bus support. However, it would be nice if Microsoft would just add it in. I don’t know how many Azure customers are using Service Bus, but it’s a pretty big feature of Azure; no matter how much cooler some of the Machine Learning or other newer features are.
