Tags :  

Azure Service Bus, Event Hub, Event Grid – which one to choose?

Last updated on: August 24, 2017

Azure Messaging Service

When more and more technologies are at your disposal doing pretty much identical things it becomes confusing to decide which one to chose and what is the benefit of choosing one over the other.

Free download this blog as a PDF document for offline read.

At the face of it, the technologies might look like they are doing pretty much the same thing, but there might be significant differences and there is a reason for their existence.

Azure Service Bus, Event Hub and Event Grid are the key Azure messaging services available in Microsoft Azure today, in fact, all these three technologies are built and maintained by the same team. Why do you need 3 different technologies for Azure messaging?

Recently this question came on one of the internal Azure Service Bus Advisory meeting and Dan Rosanova (Principal Program Manager Lead) gave a great explanation taking an E-Commerce example where you use different technologies for different types of messaging in the same solution.

It’s a great explanation and gives great clarity, hence I documented it here. Also, you can check this technology page Azure Service Bus for detailed understanding about the technology.

Azure Service Bus

Azure Messaging Services

When you have a shopping cart, when you’re buying stuff, and when you’re moving money or material you would probably use Azure Service Bus because you want transactions, you want instantaneous consistency, you want to be able to have temporal control like if this is not processed in x amount of minutes then dead letter it or send it somewhere else for an escalation. When you want these kinds of orchestrated (workflow) stuff to do state transitions then you’ll be using Azure Service Bus. It’s really like IBM MQ or BizTalk Server, however at cloud scale. In a nutshell, when you need robustness and cannot afford to lose any messages, you’ll go for Azure Service Bus.

Azure Event Grid

Azure Messaging Services

When you’re actually shipping and moving stuff, where you are reacting to things like item has been pulled from the shelf, item was bought to postal area, item has been shipped, or this shipment was rejected and so on, in this case instead of doing a central control workflow you would do in an Event-based model running active workflows for each product item.  Here you are reacting to real changes in real time. Azure Event Grid is ideal for these kinds of reactive scenarios. 

Azure Event Hub

Azure Messaging Services

Azure Event Hub is used more for the telemetry scenarios. Let’s say if every component that’s been used in the Enterprise for this e-commerce application emits telemetry data like Log4Net or Log4J and you wanted to capture it, then you’ll use Azure Event Hub. A great example is Azure Application Insights, under the hood it uses Azure Event Hub to capture the telemetry information.

Also, check out this blog to understand the capabilities of Azure Event Hubs and Service Bus messaging platforms.

Hope this helps to clarify the need for 3 different messaging platforms in Microsoft Azure and when to use them appropriately. 

Author: Saravana Kumar

Saravana Kumar is the Founder and CEO of Kovai.co. Entrepreneur, Investor, and Technical enthusiast. Passionate about running and scaling a company in a profitable way with calculated risks.

9 thoughts on “Azure Service Bus, Event Hub, Event Grid – which one to choose?”

  1. Is Azure Service Bus more like MSMQ as you folks said this is more like IBM MQ? I tought this is more like the IBM Message Broker that can actually do lot more than Data Plumbing?

    1. Azure Service Bus is more like MSMQ/IBM MQ just a queuing technology. IBM Message Broker equivalent will be BizTalk Server on on-premise and combination of bunch of technologies like Logic Apps, Service Bus, Event Grid, Functions on the cloud world.

  2. Does event Hub and Event Grid support a FIFO mechanism. Also Event Grid is like Kafka. Am I right in saying this.

    1. Event Grid will not support FIFO since it’s a loosely coupled pub/sub engine. Event Hub will support FIFO in incoming persistence, but on the reading side the data is not removed from Event Hub like queues, the data stays in the Hub and can be read multiple times.

  3. After reading it I still have many doubts. You gave use cases for each product but didn´t explain the reason or disadvantages of using the other products in those use cases.

Comments are closed.