|
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. |