Implementing scalable messaging patterns in Azure - Will Velida - NDC Sydney 2024
ฝัง
- เผยแพร่เมื่อ 29 ก.ย. 2024
- This talk was recorded at NDC Sydney in Sydney, Australia. #ndcsydney #ndcconferences #developer #softwaredeveloper
Attend the next NDC conference near you:
ndcconferences...
ndcsydney.com/
Subscribe to our TH-cam channel and learn every day:
/ @NDC
Follow our Social Media!
/ ndcconferences
/ ndc_conferences
/ ndc_conferences
#architecture #microservices #cloud #microsoft
With the distributed nature of cloud applications, we need messaging systems that helps us connect the various different components and services that make up our architecutre, while remaining loosely coupled to ensure that we can scale when needed.
In this talk we'll start by doing comparing between different messaging services in Azure, and understand which service is appropriate to choose in which scenario. We'll then dive into the different messaging patterns we can implement in our architectures, what scenarios they would be appropriate for, and any issues and tradeoffs we need to consider when implementing them.
By the end of this talk, you'll know which messaging service to use for which use case, as well as various different messaging patterns that you can implement to build loosely coupled, but highly scalable messaging systems.
How many services worldwide which are not media streaming services are running constantly in an interoperable manner to require all these?
One of the takeaways of this talk is that you don't need to implement all those patterns. Just the one that fits your use case 53:15
Hi Will, awsome recap of azure offerings. Just a suggestion to maybe mention event sourcing and/or (transactional) outbox pattern and even CDC next to sagas to solve similar problem
Please correct me if I am wrong, but there is currently no built-in Azure solution for event sourcing. Azure service bus kinda-sorta could be used for it, but it comes with a very short message storage limit, 14 days, I believe. You would need something else to store events, if you expect the system to run for longer than that.
Apart from telco services with specific protocols or standards (such as SMS, RCS…) I would say… none 😂
53:15 👍