Introducing the new Azure Service Bus transport for .NET Core

The wait is over! Today we’re releasing the new Azure Service Bus transport, which is fully compatible with NServiceBus 7 and .NET Core.

You will now be able to run NServiceBus endpoints using Azure Service Bus anywhere.

With the release of the new NServiceBus Azure Service Bus transport, we are now able to take full advantage of .NET Core and Azure. Getting up and running was simple and we don't have to worry about managing and maintaining queue databases anymore. Being able to use NServiceBus on .NET Core means we are now able to run our endpoints as Windows services for our on-premises clients and in Linux containers on Azure for our SaaS customers, using the same code! Mark Gould, Solution Architect
Spindlemedia, Inc.

With this news, we’re rebranding the previous transport as the “legacy” Azure Service Bus transport. Just as Microsoft will not be adding new features to their legacy client, we won’t add any new features to the legacy transport that uses it. The legacy transport will receive only critical bug fixes and security patches from this point on.

However, you can rest easy knowing that you will have a documented and supported migration path that will allow you to gradually transition your current system to the new transport.

Here’s what you need to know.

🔗The new transport

The new Azure Service Bus transport uses the also-new Microsoft.Azure.ServiceBus client library to target .NET Standard 2.0. This new client library from Microsoft, which was for some time not feature-complete, was the main reason why we were unable to release the new transport immediately with the release of NServiceBus 7 for .NET Core.

Some features that the legacy transport accumulated over the years have been left behind. Because of the clean break Microsoft made from the older Service Bus client, the new Azure Service Bus transport for NServiceBus represents a clean break from the (now) legacy transport as well.

In most cases, the features that have been removed were conceived of in the first few years of Azure Service Bus. Since then, the service has matured significantly, and many of these features are now provided directly by Microsoft at the service level. It simply doesn’t make sense to continue to support these features in a new transport when Microsoft’s implementation is much closer to the metal.

A prime example of this is multiple namespaces. The legacy transport offered the ability to provide the connection strings for multiple namespaces to enable some measure of high availability. Fast forward to the present, and the Premium Tier of Azure Service Bus now uses Availability Zones to provide high availability transparently to the client using one connection string.

🔗Migration

No matter how you’re using the legacy Azure Service Bus transport today, we have a path available to migrate to the new transport when you’re ready.

If you’re already using the forwarding topology with the legacy transport, then your system is already compatible with the new transport, under certain conditions. Assuming these are met, you can upgrade directly to the new transport.

If you are using the endpoint-oriented topology, which we have advised against for some time, you will first need to migrate to the forwarding topology. However, this migration can be accomplished with zero system downtime.

To facilitate the migration, we released a minor version of the legacy transport that included a migration feature. This feature operates the transport in a migration state where an endpoint can continue to communicate with other endpoints running either topology.

In the first phase of migration, all endpoints are upgraded so that the migration feature is enabled, one endpoint at a time. Once all endpoints are using the migration feature, the second phase can begin, where all endpoints are then converted to use the forwarding topology. See the upgrade guide and migration documentation for more details.

Once on the forwarding topology, the migrated endpoints are then compatible with the new transport and can be upgraded at will, assuming the previously mentioned conditions are met.

🔗Premium vs. Standard

Going forward, we recommend using Premium Tier namespaces to get features that the transport no longer implements directly, such as High Availability, because these features aren’t available in the Standard Tier.

We recommend all customers use the Premium Tier for production workloads. The shared environment of the Standard Tier simply isn’t appropriate for anything but systems with very low message volumes or systems still in development.

When we attempted to do performance testing of the new transport to compare it to the legacy transport, we discovered that it is essentially impossible to run benchmarks on the Standard Tier. The performance of that tier is best described as completely random, as it is subject to all sorts of throttling and noisy neighbor problems.

🔗Summary

The new Azure Service Bus transport is here, and it’s the future. Anything new coming from Microsoft will only be available via the new transport and the new transport alone. We would like to do whatever we can to ensure everyone using the legacy transport is able to migrate and upgrade as soon as they are able.

We’d love to talk to you about planning your migration. Reach out to us via our support channels and we’ll be happy to talk.