My most popular blog post explains the key differences between Azure Service Bus and Event Grid.  At the time of writing, Event Grid only supported push delivery.  However, with the introduction of Event Grid Namespaces, it now supports pull delivery for custom events.  This new feature makes it even more difficult to make the right choice.  In this blog post, I try to list the main differences.

Protocol

This is by far the biggest difference! Azure Service Bus is built on top of the AMQP protocol.  Within the AMQP protocol, the receiver decides when it’s ready to process messages.  However, once the connection is established, messages are pushed from the broker to the client. over that connection.  This results in optimal and high throughput.

Azure Event Grid Namespaces are built on top of the HTTP protocol.  The receiver must poll for new messages.  This results in lower throughput.  Luckily, the polling mechanism is optimized. When you poll for messages, Event Grid will wait up to 60 seconds for new events to arrive.

Payload and filtering

In Azure Service Bus, the payload can be anything and it gets accompanied by additional metadata.  This payload has a maximum message size of 256 KB, unless you are using the premium tier that supports messages up to 100 MB.  The metadata is used to filter the messages that end-up in the subscriptions.  This filtering can be quite advanced, when using the SQL filter capabilities.

Azure Event Grid Namespaces expects a CloudEvent 1.0 event, using the HTTP protocol binding with JSON format. Because the CloudEvent specification is envelope-based, the metadata and the message body are sent together in the payload.  Batching is supported.  The maximum event size (batch or individual) is 1 MB. Filtering is typically done on the EventType and Subject, that are provided in the CloudEvent envelope.  Advanced filtering can be performed on the other data in the CloudEvent, using the following operators:

Reliability

While using other terminology, both implementations use the principle of the peek-lock pattern to ensure at-least-once reliability.  In Azure Service bus, you peek a message, you complete it when it’s processed or you abandon when you want to stop processing that message.  In Event Grid, you receive an event, you acknowledge it when it’s processed or you reject when you want to stop processing the event.

Both services have a maximum lock duration of 5 minutes and a maximum delivery count of 10, unless you are using the Service Bus premium tier.  The retention in Azure Event Grid must be equal or lower than 7 days.  In Azure Service Bus, this maximum time to live is 14 days or more, depending on the tier.

In Azure Service Bus, deadletter queues are built-in.  For Azure Event Grid, deadlettering is done in Azure Blob Storage.

Maturity

Event Grid Namespaces are brand new, so they have some missing features.  Two important ones that I already noticed:

• You cannot inspect messages that are queued inside your subscription
• You cannot disable local authentication (yet?), however the docs already mention it

Be aware that Azure Service Bus is purpose-built for asynchronous queuing scenarios, so it includes some important features that Event Grid namespaces will probably (?) never implement:

• FIFO (through the use of sessions)
• Duplicate message detection
• Prefetching of messages
• Auto-forwarding
• Advanced correlation
• …

Pricing

Let’s compare the pricing with of Event Grid Namespace, with Azure Service Bus Standard, because both include topics and subscriptions.  Event Grid has a base price which is 3 times higher than Service Bus.  Event Grid has also less free included operations and be aware the the polling of the pull delivery might increase the number of operations.

• Service Bus Standard:
  • Base charge of less than 10 EUR per month for one messaging unit
  • 0,73 EUR per million operations (13M operations included, price decreasing when # operations increase)
• Event Grid Namespace
  • Base charge of 27,5 EUR per month for one throughput unit
  • 0,547 EUR per million operations (1M operations included, stable price when # operations increase)

The pricing of Event Grid becomes very attractive when private networking is required.  Azure Event Grid Namespace can rely on private endpoints, which means you have private access for an additional 6 EUR per month.  Unfortunately, the Service Bus architecture does not support private endpoints.  As a consequence, you have to purchase the premium tier for full network isolation, which comes at a price of more than 600 EUR per month.

Conclusion

A new kid on the messaging block!  When you are looking for traditional queuing scenarios, Azure Service Bus is still the way to go.  When looking for simple publish-subscribe broker, using the HTTP protocol, Azure Event Grid namespaces is what you need.  Because of this HTTP protocol, it is a very good match with Azure Logic Apps.  I will discuss this in a follow-up post!  Be aware that Event Grid Namespaces is a little bit more expensive, but its price becomes very competitive if private access must be ensured.

Sharing is caring!