Service bus management – here's a way
UPDATE: this post contains a lot of additional great suggestions
How to create a consistent DTAP environment, which standards to adhere to, what naming conventions to apply, how to document these….all questions….the answers….a little cloudy. In this post I show how I use the tool Service Bus Explorer to my advantage for some of these questions.
· Goal: create a consistent environment for DTAP
· Challenges
1. Naming conventions on Windows Azure (sb / queues / topics etc)
2. Isolation of environment and thus billing
3. Repeatable steps / Configurable using a tool / xml configuration
#1: Naming conventions
Are they out there for Azure? This is a future subject for a WindowsAzure live chat session.
· My #1 rule: make sure that the naming convention you think of are consistent
· An example convention: <Customer><Project><Type><Artefact> (Contoso.Broker.Transform.FormatA2FormatB) would not translate well to an Azure queue or service bus due to the long name, so we need to split this up into smaller pieces, a way could be
1. Create a subscription for the customer
2. Start the entity name with the project
3. The Azure Portal already takes care of separating the artefact types, so pre- postfixing it (sbbrokerorders / brokerqorderinqueue or brokerorderinqueue) would not improve or help in maintainability, this is up to you.
#2: Isolated billing
The only way to really isolate the billing, is to create several subscriptions. This is my recommendation anyway, as migrating subscriptions is something that you do through a support call and is thus out of your control in situations mentioned in my previous post
Dedicated service bus namespaces will show up in a different line in the exported bill as shown in the exported bill below
#3: Repeatable steps / configurable using a tool / xml configuration
My approach is shown in below and is applied on service bus namespaces and Queues. However, this is because the tool I’ve chosen is Service Bus Explorer, I’ve suggested this type of abilities to several vendors as they were open to feedback, so who know, this type of approach might become possible for all tools / portals.
Consider my list of service namespaces:
· Sbprojecttest
· Sbprojectdev
There is a precompiled version already included in the release, you can also start visual studio and build this one.
· Open the ServiceBusExporer.Exe.Config
Add the different namespaces you want to manage from ServiceBusExplorer as shown in the picture below.
· Start Service Bus Explorer and connect to a service bus namespace (from the config)
· Connect to the environment
· Create the queues we would like to deploy consistently
· Export the entities
· View the exported settings
This is the first step, this config file is now exported as Xml. We can view all the settings and use a tool or program to manipulate this configuration file. We can add this configuration file into TFS etc.
· Connect to a different service bus namespace (e.g. sbprojecttest)
We can see that at this point, there are no queues….
· We will import the entities using the configuration file
· The import will create the queues with the specified settings in the configuration file
· In Azure, we now have 2 service bus namespaces, with a consistent configuration
Note: Yes, you can always use PowerShell. For my case, I wanted an approach I can easily explain to anyone capable of using a computer without installing anything. Additionally, you need to create these scripts yourself, as it is now, there are differences in On Premise Service Bus and Azure Service Bus, so that didn’t work for my scenario. Additionally, I only needed to retrieve the service bus namespace connectionstring and configure this in the Service Bus Explorer, and didn’t had to retrieve the publishsettings etc.
Note 2: Managing and Using the Queues should be separated (IMHO). By using a tool like Service Bus Explorer to create a consistent environment using config files or by using powershell. If your code creates a queue when it’s now there, shouldn’t an alarm go off? Aren’t the queues durable, and always available, I assume yes and like to monitor for this particular situation, as it’s probably a showstopper.
Note3: You can also create a dedicated subscription for DEV/TEST/ACC for each service bus namespace (depending how much you like to manage). For production it would be best to always create a dedicated subscription.
HTH,
Sander
Comments