Reviewing Azure's Comparison of their Messaging Services

,
1

Microsoft/Azure has a topic titled “Choose between Azure messaging services - Event Grid, Event Hubs, and Service Bus” that feels very different to much of the writing I’ve read from Particular over the years. I’d like to hear a response from those in/around Particular about their thoughts on the topic, and how NServiceBus differs in approach/thought to what Microsoft is pitching.

For example, as a 5 year NServiceBus user, their definition of events vs messages sounds like heresy, and then the feeling that you should use certain services (i.e. transports) based on which design pattern you’re trying to accomplish also seems odd (pub/sub = event grid, series-based-events = event hubs, everything else = service bus). Of course, NServiceBus chooses to do all of the above in Azure Service Bus (though it doesn’t encourage all of the above!), and I’m sure the same could be said about the other services.

Thoughts?

1 Like
2

Talk about a doozy of a question. :wink: I’ll just start off by saying that what follows are my very quick personal thoughts. We did not edit or workshop this internally at Particular. Some of my colleagues may even disagree with what I say, and that’s OK.

I think at its core this comes down to the fact that naming things is hard.

When we talk about “events” at Particular, we really mean business events - something that is happened (irreversible, in the past) that is published (low coupling) to any subscriber who is interested. But to us, all events are messages too but by attaching the “event” moniker to it we just mean that it gets published to multiple locations.

In the article you link, Microsoft absolutely does not appear to be the same definition of the word event. I think it makes sense within the scope of that article, but there are only so many words to choose from.

In the Microsoft article, I think that very first sentence is telling…

An event is a lightweight notification of a condition or a state change.

By this definition, any app running in Azure is swimming in a sea of events before you even get to the very first line of your application’s code. File updated in blob storage, virtual machine CPU exceeded threshold, Azure function fired, media services job state change, app config value modified, App Service slot swap, I’m sure there’s literally hundreds already being created by Azure services.

So these are not business events, these are technical events. Some of them might be business events. Perhaps blob uploads in a particular location qualify to you as a business event. But not all. And you could certainly use Event Hubs or Event Grid to “promote” an interesting technical event into a much more important business event to be processed with Azure Service Bus.

And it appears at least part of this naming scheme is because Azure has chosen to name these two services “Event Grid” and “Event Hubs”. Those would be pretty silly names if the things they handled weren’t “events” right?

So then everything else, the important business events, are really “Messages” in this article. In the article’s definition, it doesn’t seem to care whether these are (using NServiceBus terminology) one-way commands or multicast events. It’s just the “stuff that Azure Service Bus handles.”

So then the difference between Event Hubs and Event Grid is that Grid deals with the little technical events that have no relation to each other (blob uploaded) where Hubs deals with changing values of a given thing (like a VM’s CPU or GPS data being transmitted from a fleet of trucks in an IoT approach).

So I don’t really think that there’s any lack of alignment between that article and anything you’ve done with NServiceBus, it’s just that the lack of unique names makes everything really confusing at first glance.

1 Like
3

Thanks David! I think your distinction between “business event” and “technical event” really helps.