
Introducing Event Grid: the first fully-managed event routing service - dynamicwebpaige
https://azure.microsoft.com/en-us/blog/introducing-azure-event-grid-an-event-service-for-modern-applications/
======
djrosanova
I'm from the product team for Event Grid and happy to answer any questions.

~~~
applejuice0
Can you please clarify/confirm the next points

1) Event Grid is similar to Amazon SNS => push messages to many kind of
subscribers. EG guarantees delivery of a message on the transport level. What
is going in case of the failure calls after resending attempts (dead queue or
something)?

2) EG is a very different beast in comparison to Azure Event Bus. EG is the
magical connector for different endpoints, while AEB is the robust storage of
events + limited publisher. Is it correct?

~~~
djrosanova
Let me try my best at this. SNS is a sort of close analogy, except SNS isn't
really natively tied directly in the other AWS services. It is from some, but
it's more attached, not natively integrated including from RBAC / security and
provisioning standpoint. Also, while SNS does have topics, and is a type of
pub-sub, it doesn't have filters. So every subscriber gets every message. This
is certainly useful, but filtering is also useful.

About the dead letter part. Today Event Grid doesn't give you a place to dead
letter, after 24 hours of failure we will drop your messages. We will tell you
we have begun dropping and when we have stopped (when you come back online).
Also soon we will let you send to queues or Event Hubs if you prefer a pull
rather than push model of webhooks.

On the second part, the two other services in Azure you may be thinking of are
Azure Event Hubs and Azure Service Bus. Event Hubs is a telemetry streaming
platform. It's really quite like Kafka. You get a stream that you can send
tons of data to for free, then have a client side cursor to read over it.
Service Bus on the other hand is really an enterprise messaging service, with
rich features like duplicate detection, scheduled delivery, deadlettering,
strict ordering, sessions, all with a service side cursor. Service Bus is much
more like IBM MQ or TIBCO.

Event Grid is meant to fill a different role: cross cloud eventing, there
events are push and they're usually shoulder taps to the source.

A single application could well use all three, but they would be for different
purposes. Service Bus fits well for financial / material changes to things.
Event Grid allows all the components to communicate with each other and
interested parties (e.g. tell me when inventory is pulled), and Event Hubs
would be the telemetry pipe from all of the components and apps.

