The Azure Service Bus Messaging Broker, the Service Bus Relay, and the Azure Event Hubs service are all siblings from the same home. If we’re counting early incubation and beta releases, the Service Bus Relay will celebrate its 10th anniversary as a cloud service this year, on May 31, 2016.

As the use of messaging patterns across the cloud platform has evolved, we’ve been adding new capabilities, such as Azure Event Hubs or Azure Notification Hubs into Service Bus and until not too long ago, you could create a Relay and a Queue and an Event Hub and a Notification Hub all alongside each other inside the same Service Bus namespace.

If you’ve been following the evolution of these services over the past couple of years, you will have noticed Notification Hubs grew up and left home, and that you need to create specific namespace type for either Messaging  (Event Hubs, Relay, Broker) or Notification Hubs.

What’s also noteworthy is while Azure IoT Hubs is also a cousin of the Service Bus family, it has been built as a separate standalone service from the start, while it could theoretically have been integrated with Service Bus into the shared namespace model. With good reason.

All of the Azure Messaging services are experiencing exceptional growth and we’re constantly adding more capacity. Exceptional growth translates into exceptional load on the production systems, and while the services all move messages in some way, the capabilities they provide are all quite different and each call for a different architectural approach.

Notification Hubs is a big fan-out engine, Event Hubs is a big fan-in engine. IoT Hubs optimizes for a huge number of concurrent connections. The Broker’s Queues and Topics provide deep and powerful messaging features, and the Relay builds connection bridges across NATs and Firewalls.

Today, all these services are already implemented and run separately, but Event Hubs, Relay, and the Broker still share a common gateway infrastructure where your Service Bus namespace is anchored.  A namespace name in Service Bus, like “clemensv.servicebus.windows.net”  directly translates into a DNS name, and thus also directly to a some network address.

To accommodate the growth driven by your workloads and to optimize the services for their specific performance and reliability needs, we need to let each of them have their own gateway. This means we need to have network addresses and therefore DNS names and namespace names separated by the kind of service you are using.

After May 1, 2016, in addition to Notification Hubs being separate, there will also be separate namespace types for Event Hubs, Relay, and the Broker (Queues and Topics). This change will affect only newly created namespaces. Any existing namespaces will work as they do today.

If you want to use a mix of these services from one application, you will from then on create and use separate namespace configurations.  The APIs will remain unchanged.

Prepping for the change

In preparation for this change, we recommend you take a look at how you use Service Bus, and make sure any application using a mix of Event Hubs and Relay and Broker inside the same application, has a way to maintain separate namespace configurations, such as a connection string, one for each service you use inside the application. At present, our data indicates such mixed-use applications are not very common and we believe the required changes can be made fairly quickly.

If you have concrete concerns about these plans, let’s talk about them. We’re reading the Service Bus Forum or you can comment directly on this blog post in the space provided below.

In special cases, we will be able to create the current “mixed” namespaces for after May 1 through the Azure support channel until the capacity is exhausted.  However, we will not be able to provide an assurance about how long such exceptions can be granted.