Messaging tools in Azure
Why do we have so many messaging tools in Azure?
Looking more closely Messages are of two types
- Intent
- Facts or Events
If a publisher has a certain expectation of how the published information item ought to be handled, and what audience should receive it, whether it's issuing a command, assigning a job, or handing over control of a collaborative activity, then it is an Intent.
Events generally don’t convey a publisher intent; an event captures the fact and conveys the fact. A consumer can process the fact which doesn’t fulfill any specific expectations held by the publisher
There are two types of events
- Discrete
- Series
Discrete events don't happen continually. They are discrete business logic activities. (Onboarding a student, Student completed one activity) They are Independent, they report a state change and mostly they are actionable.
Series events are a continuous stream of data. They are time ordered, Data in this stream are related to each other. Individual events don't add more value (Log data, stock market ticker) (One 502 error log is of zero value, but hundred 502 within 10 mins is a valuable information)
While these are all messages, with different usage scenarios Microsoft Azure provides a differentiated portfolio of services.
If the message is “series events” then Azure Event Hubs should be our tool of choice.
If the message is “Discrete events” then Azure Event Grid should be our tool of choice.
For all the other types of messages, which demand a solid platform for workflow and transaction handling then Azure Service Bus should be our tool of choice.
Composing “Event Hubs” with serverless functions may work functionally but will make a big dent in your wallet. So, choosing the right tools will make the product scalable, maintainable and economically viable.
