What are the pros and cons of using AzureServiceBusMessageQueue vs. AzureMessageQueue?
I understand that there are differences between these 2 transport bindings on Azure alone, such as message size, concurrency, duplication behavior etc. However much of this is already being coordinated by NServiceBus (or so I presume - because NServiceBus documentation is very scarce on the subject). NServiceBus itself allows you to store the payload in a blob storage.
So then what are the pros and cons of using one as opposed to the other? I'm mostly concerned about the: performance, scalability, payload limitation, flexibility to move solution on and off premise and cost.
I would say that the Azure Service Bus Queues/Topics provide much more flexibility and features in general. If you look at the investments of Microsoft, I would also claim that they put more investment on the service bus messaging compared to the storage queues.
I agree that NServiceBus provides some features that are also provided by these service bus queues in general, but then it's up to you to either use them or not.
You might look at pricing differences, but the good thing with service bus entities is that you can have (very) long timeouts when listening for messages, which reduce the number of transactions you pay for. As far as I remember (been a while since I used storage queues) that's not the case with the storage queues
HTH