Why would I use AzureServiceBus as a transport in NServiceBus?
Azure Service Bus is not a trivial dependency. There are things such as retries and intermittent errors, connectivity handling, serialization and deserialization, message size constraints, transaction management, and more that you might not want to do yourself or have it in your code. That's where NServiceBus comes into play. It also brings some additional benefits you might not necessarily consider in the early days. Such as tooling for operations (monitoring, manual retries, etc). The programming model it provides gives you an abstraction over many concepts, allowing you to eventually move to another messaging service if needed.
From a business perspective, developers can focus on the business problem, rather than spending time first on building middleware to handle Azure Service Bus, and later integrating middleware support into budgets allocated for business problems/products. The cost of NServiceBus compared to the cost of the development time, combined with the on-going cost of Service Bus related code maintenance and bug fixes, is minuscule. In the same way that companies, when building business software, don't build their own operating systems, our customers choose to focus on their core business, leaving messaging infrastructure to NServiceBus.
Disclaimer: I'm involved in developing NServiceBus and a contributor to the Azure Service Bus transport.
