Azure Service Bus - Getting Started

#servicebus #microservices #dotnet #messagebrokers
00:00 Intro
00:31 Introducing Azure Service Bus
01:45 Benefits of PaaS
02:12 Kafka & Azure Event Hubs
03:09 Azure Service Bus Features
06:35 Setting up Azure Service Bus
13:53 Starting with C# Code
14:50 The Publisher application
21:12 The Subscriber application
27:08 Competing Subscribers - Running multiple instance of the consumer
29:08 Creating a second Subscription using the Azure Portal
30:22 Multi-threaded application subscribing to multiple subscriptions
39:59 Advanced Features of Azure Service Bus
Build reliable and elastic cloud apps with messaging
Protect your application from temporary spikes in traffic
Decouple your applications from each other
Connect your existing on-premises systems to cloud solutions
Distribute messages to multiple independent back-end systems
Scale out ordered messaging to multiple readers
Depend on Azure Service Bus when you need highly-reliable cloud messaging service between applications and services, even when one or more is offline. Available in every Azure region, this fully-managed service eliminates the burdens of server management and licensing. Asynchronous operations give you flexible, brokered messaging between client and server, along with structured first-in, first-out (FIFO) messaging, and publish/subscribe capabilities-excellent for tasks like order processing.
The Visual Studio Solution and code used in this video is available here:
github.com/matlus/AzureServic...

[@jagkoth]

wow your voice is so cool. I hope you do podcasts :)

[@Matlus]

Maybe one day!

[@thisguymartin]

Dude that voice !! You should be a voice actor as like some bad ass boss

[@Matlus]

LOL. Thank you Martin. I guess I'll have an alternate career once AI takes over out jobs :)

[@VinuP2023]

Shiv, please beware of spammers as in the first comment and block them if possible. :)

[@HIOLLJ]

Good work, Shiv. A suggestion, if you will, I could see that you used Task.StartNew() for firing multi-threaded tasks. As it turns out, there are known issues with the StartNew method where you'd expect it to start the task on a thread pool's thread instead it starts the task on the calling/main thread. You can go for Task.Run() which is much cleaner and guarantees the fact that the task will be picked up by a thread from the thread pool.

[@Matlus]

Hi Gourav, I don't see that issue. None of the tasks are running on the main thread and I see that random threads are picked up from the threadpool. I initially had Task.Run but at some point I switched over to Using TaskFactory.StartNew. I'll do some more tests and let you know if I find something.

[@gladiator2017]

Hi Shiv, thank you for this nice video. We also use service bus in our applications, also we set the max concurrent calls and prefetch settings while configuring sbus subscription client to increase throughput. Also I would like to see some videos on the topic of Retry using Polly library, especially in the context of dotnet core httpclient. I would like to know the best practices with retry, exception handling, logging, best practices with circuit breaker, timeout handling , gotchas with async and polly and most importantly getting the actual exception from upstream endpoint call after final retry, so that we can read the response payload in the http response exception and do some action based on that. I have searched for getting the actual http exception/ payload from upstream after the final retry is completed, but couldn't find anything. After final retry, polly gives back only TaskCancelled exception always and not the actual exception from the upstream endpoint. It will be great if you can throw some light on the intricacies with polly. Thanks in advance !

[@JasonDias7]

Why do you need polly? Azure service bus has resiliency built in. If the message is not acked successfully, it retires. Also if you are planning on using polly for api requests. You could add retry at api gateway level, offload cross cutting concers.

[@raviakella2877]

Really Nice Presentation Shiv !! . It takes some time to adjust to your presentation style .. may be calmness.... once done it's smooth !!. Thank you.

[@Matlus]

Hahaha....good to know!

[@colebq]

Hi Shiv, thanks for the great video. Regarding the colors, I assume the console color update and the write need to be programmed in a thread-safe manner.

[@Matlus]

Thank you colebq!. Yes, that's correct!

[@saurabhchauhan232]

With the redfont settings on dark theme it's hard to read what is written there. I can see on github but if you can consider choosing different color it would be really helpful. Sometimes I watch from mobile and from mobile it's hard to read what's written. Thanks for the video Sir.

[@Matlus]

Yes, I've got this feedback from someone else as well. I'll change that color and see how it goes

[@miroslavparvanov]

Thank you for the video! It would be cool to hear your opinion about Microsoft's Ambrosia project. It's still experimental but looks very promising. It promises "exactly once delivery" and "exactly once execution".

[@Matlus]

Great suggestion! Thank you.

[@danielvillalba4457]

This is an amazing video as always Shiv, you find the way to explain things in a very easy to follow manner thanks for that. Now I do have a question, I have a requirement where we need to implement a message broker component to our architecture and we are looking at Service Bus because my company has a partnership with MS, anyway I'm planning to use a queue (not a topic/exchange) and set my subscribers as a console app that runs under a BackgroundService on Docker, now from this video I saw that there is no additional configuration required to setup competing subscribers right ? It is all being handled under the hood by the QueueClient (in my case) and the Service Bus Queue as far as I can see, I'm about to do some tests on my local machine though but any feedback from your side on this subject would be highly appreciate it in order to take the next steps with confidence. Thanks again for this awesome videos!

[@Matlus]

Thank you for your kind words Daniel! In order to have competing subscribers you need to set anything up especially in ASB. You may want to look at receiving 1 messages are a time through rather than a batch of messages. This needs to be set up in Azure you you set up the subscriptions. Also each competing subscriber will need to have a unique identifier. Since the source code is generally the same, you'll need to have a way to generate a unique identifier for instance of your subscriber application. Hope that helps.

[@danielvillalba4457]

@@Matlus got it, about the each subscriber's unique identifier it's basically for traceability matters right? I'm thinking on use the docker container If since basically each of this subscribers will be self contained I can use that, is it the right approach!

[@danielvillalba4457]

@@Matlus docker container Id

[@Matlus]

@@danielvillalba4457 Subscribers need to be unique. Not just for traceability though. Message brokers require that. You can use anything you desire as long as they are unique. In the case of competing subscribers, the identifier needs to be the same so that the message broker recognizes that the subscribers are the "same" and thus competing subscribers,

[@saurabhchauhan232]

is there any limitation with how much work the messag subscriber application do example Ordershipped do another 2-4 call like confirmation email, call tracking api send tracking email , update db. Or it needs to be divided in part like the Mesaage broker introduction video or you said each event should have different queue so Ordershipped subscriber publish message to another queue like Order tracking queue, so my doubt is subscriber can do long work or it needs to be short enough?

[@Matlus]

There is no limit per-se. It's just another application. But you may need to take into consideration the rate at which messages arrive and the rate at which you consume messages. If consumption is slower because of all of the processing then you may need to use the competing subscriber pattern