Introducing Event Grid: the first fully-managed event routing service
azure.microsoft.comI'm from the product team for Event Grid and happy to answer any questions.
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?
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.
What are some of the more interesting potential implementations you've come up with for Event Grid?
Are there any planned Events or Sources for SQL Database?
Good question. Some are interesting, some are just useful. For SQL DW doing something like using Event Hubs Capture feature to trigger ETL into DW is really useful. And generally interesting. For Any datastore (SQL, CosmosDb, others) being notified of create, update, or delete operations is also useful and interesting. I think broadly speaking the three areas where Event Grid will be very interesting are for
Serverless: tie your serverless functions together with Grid.
Operations: make rich provisioning and deployment or scale experiences.
Enterprise integration: use workflow and orchestration services like Logic Apps to perform integration across cloud services, cloud providers, and on-premises.
Finally, the custom topics stuff really makes not just serverless, but any cloud application have some interesting possibilities for event and data distribution and publication.