Azure User Group Sweden: Fire & Forget with Azure Service Bus

Name: Azure User Group Sweden: Fire & Forget with Azure Service Bus | Humix Video
Uploaded: 2023-11-01T16:36:15+00:00
Duration: 1 h 3 min 56 s

0:30
Hi, welcome to Azure User Group Sweden
0:40
Happy weekend, everyone. Hi, Håkan. Hello, Jona. Hi. How are you doing
0:45
I'm great. It's very, it's sunny today outside. So it feels like the winter is over soon for us here mid-north of Sweden
0:56
How about you there in Oslo? So according to the forecast, it will be the warmest day of the year so far, I think, plus 18 degrees
1:06
Yes, yeah, I really look forward to summer. Yes, and to those that are tuning in to us live today, thank you for joining us
1:16
And I hope that you're having a great time tuning in. And today we will be having a session of one of our community members at Azure User Group Sweden
1:30
And it's an honor to have him with us today. And before we get started, let me just introduce ourselves to those that are joining us first time
1:42
So let me introduce Håkan Silvernogl. He is a community leader at Azure User Group Sweden
1:50
He is Microsoft AI MVP. He works as a manager for big data and AI at Miles
1:58
And he is also very active in other communities like ambassador of Oslo AI, community leader of Norwegian .NET user group, and also an AI school called AI42
2:11
And he is also a public speaker and a lot of things. So it's a great pleasure to collaborate with Håkan in this community
2:20
Yeah, thank you. Thank you, Jona. And it's also a pleasure to me to introduce Jona, Jona Anderson, who is the founder of our user group. She is a Microsoft Azure MVP and also Microsoft Certified Trainer
2:33
She is also a mentor, a public speaker, a podcast host, and she works in her daily job as a cloud and DevOps engineer
2:45
And she is also writing a book, which is soon to be released here on O'Reilly
2:52
Yes. Do you want to say something about your book, Jona? Yes. My book is about learning Microsoft Azure and it will be a fundamentals book for developers and those that are still starting their journey with Azure
3:08
And it's all about Azure as well, which is our community. So I really look forward to that
3:15
And actually recently I found out what will be the animal of my book. So I was so happy, but I'm not going to disclose it until it's time
3:23
Yes, that's great. Okay. Yeah. Thank you for the great introduction, Haukan. And before we kickstart our session today and introduce our speaker, let me just share to everyone about our community code of conduct
3:41
So we expect everyone to be nice and friendly, listen with purpose and be thoughtful, be respectful to others, try to understand others, not criticize
3:54
Be curious to share your ideas in the chat or even in our after session of Vicas with the community and be inclusive with your questions and comments
4:07
And if you have questions regarding our code of conduct, feel free to reach out to me and Hocan on LinkedIn
4:17
Okay. And do you want to share about our Azure Learner Heroes, Hocan
4:23
Yes. So we're also very happy to be able to offer you a learner badge
4:29
So you can claim your learner badge here and also find out about the learning path
4:37
So you can see the bit.ly here and also you can scan this QR code
4:43
Yes, that's right. And there's also a learning path related to the session today, which is about Azure Service Bus
4:54
Yes, and yes, and after session, we will also want, we also want to invite you for our standard after session FICA via Zoom to those who wants to continue the conversation after the live stream
5:12
Great, I'm excited. Yes, me too. So it's time for us here to introduce one of our community members and also our speaker here today
5:24
So we're very happy to introduce Nikos. Nikos Delis. Hello, hello. Hi there
5:31
Hi, Nikos. Thanks for having me. I'm very good. Yes, that's great
5:37
How are you today? Greetings from Malmo. Yeah, how are things from Malmo? Is it warm also
5:42
It is warm. It is warm, actually. It's very, very sunny, and it doesn't blow that much, as it usually does. So I don't want to jinx it, but it seems like spring is finally here
5:57
Great. Yeah. I would just like to give a more formal introduction here to Nikos. Nikos Delis is a senior cloud engineer and also a cloud evangelist. And he is six times Microsoft certified and also senior cloud architect and a tech enthusiast
6:15
and he's passionate about software architecture and solution design. And he has 10 years of hands-on experience in software engineering
6:23
and a focus on .NET-based solutions and also Azure as a cloud service
6:28
and worked on many types of applications from small Windows form tools
6:33
to large-scale enterprise web-based solution. And the more he codes, the more he'll realize that his true passion
6:39
is solution design and software architecture, regardless of tech stack and platform
6:44
and sharing knowledge and insights is the finest things he knows and the one he loves the most in the IT community
6:51
Yes, amazing. Thanks a lot. Yes. Yeah, thank you. Welcome, Nikos. And it was a great introduction by Håkan
7:02
And we are so happy to have you. So as we shared previously, April is a special month
7:07
because we have our community members who never did a lot of public speaking before are volunteering to share their knowledge about
7:17
Asher And before we continue I just want to show that everyone the friends that we have Stefan is saying hello We have Learn a learn asher with nick saying hello ashish is all here today uh deepak uh is also here and someone from senegal is also a tv channel
7:41
today all right yes and uh and nikos i know that you are uh aside from sharing knowledge you're
7:52
also doing podcasts right the asher yes can you share a bit about the motivation why you started it
7:58
uh well to be honest i got a lot uh motivated by you
8:03
yes yeah well no um it is like that that um after working for uh for a few years then you start to
8:14
realize that uh you can do a lot of things by yourself but you can do even more things if you
8:20
share your knowledge and then two people doing the thing or it's three or four or as many as possible
8:27
so when you realize that and you realize that sharing knowledge makes you actually makes you
8:34
better in what you do and then it wasn't hard to follow the path and of course I said in kind of
8:41
but I do mean that both of you and all the community members inspire me a lot and the more
8:48
content I see, the more content I want to produce. I think that we are in this thing together
8:56
All the communities all around the world, I'm very, very happy to see somebody from Senegal
9:02
today or wherever you are in the world. This is a magic that we're very happy to have in our
9:09
industry. I don't see it in a lot of other industries. So I like the climate. I like the
9:15
whole thing and it really makes me happy. Yes, that's a very, it makes me happy to see how inspired you are, Nico's, and now you're
9:25
on a virtual stage sharing knowledge, spreading it out to others that are tuning into us or
9:33
watching this recorded. Okay, great. And today you will be sharing about Azure Service Bus, one of the Azure services I like
9:43
using as well. Absolutely. All right. Yeah. Okay. So now we have the presentation on
9:53
So I'll get started. Well, as Jonah mentioned, today we're going to talk about how to implement a fire and forget
10:02
functionality using the Azure service bus. And let's start by stating the obvious that it's not a bus. Okay
10:09
There's nothing with collective traffic. There is nothing, no real bus at all
10:13
In fact, Azure Service Bus is a message broker. Before taking the bus, and although we do have the introduction
10:24
let me just shortly mention a few things about me. My name is Nikos Telis
10:29
My title and my certification have already been mentioned. I wanted to say that I also have a blog called ndtechnique.com
10:38
where I publish content about Azure, about anything that I do in my everyday work
10:49
and I find a little bit challenging, then I think that maybe I could help someone
10:54
that also would find it challenging. So I try to write a small post or something
10:58
and publish it in my blog. I also do a podcast, as mentioned, called Azure Triumphs
11:05
where I interview people who have done successful projects in Azure, and I asked them about their experiences
11:15
about what they did in that specific project without breaking any NDAs, of course
11:21
And last but not least, I try to be as active as I can in Azure communities
11:28
such as Azure User Group Sweden, the one we currently are on
11:35
And I get a lot of knowledge from there. I try to share my knowledge as well
11:41
and I would like to invite everybody who's watching this video live or in the recording
11:48
do not hesitate, become a member of the community, you don't have to actively commit something. I'm
11:55
sure you will get a lot and if you feel like that then why not share something. Now getting into
12:02
to the core presentation, the subject of today. I'll just run through the agenda
12:11
First of all, I will try to explain what is the Azure Service Bus
12:15
Then we will try to compare it with Eventbrit and Event Hub, which together with the Service Bus
12:24
are the three services that Azure proposes to use to use for implementing a message-driven architecture
12:34
We will see how we can put service bus in our architecture and what advantages do I get
12:40
We will also talk about the first in, first out pattern. We will talk about how we can schedule message deliveries
12:48
And of course, the presentation wouldn't be complete without the reference in the dead letter queue
12:54
where messages go to die. and last but not least i will try to mention a few pitfalls i will try to mention a few pitfalls
13:03
to avoid at least the ones that i have been into okay well getting started with uh as a sheriff's
13:12
bus the one-on-one as i like to call it and if you google about it and or bing about it and you
13:19
see how my shop describes it then they say that this is a fully managed enterprise message broken
13:26
with message queues and public subscribe topics in a namespace. And the service bus is used to decouple application and services from each other
13:36
So what this essentially means is that the service bus is going to be used
13:43
as a man in the middle in a communication between two services
13:47
I know that a lot of people are working with integrations where one system has to communicate with another system
13:54
I don't think there are a lot more common scenarios like that
13:58
This is one of the most common. And in such cases, you have two dependencies
14:04
So for this integration to work, both systems must be up and running
14:09
So to relieve you from this dependency, you can put a message broker in the middle
14:15
where the one system is sending messages and the other system is picking those messages
14:21
Now, as you can see, Service Pass provides two kinds of queues
14:29
Let's call them queues. The one is a queue and the other is a topic. And the difference between the queue and the topic is that a queue has one sender and one receiver
14:38
while the topic has one sender but it has multiple receivers. receivers. I have taken those images from Microsoft Learn. But there is one thing I don't
14:50
like I don like the word receiver Because as I will explain later in service bus we don have receivers we have subscribers So the one endpoint is going to send a message
15:05
and the other endpoint is not going to receive a message. It is going to pick a message from the subscription, from the topic, from the queue
15:13
This is an important detail and an important difference from the other services
15:18
I also want to mention that Azure Service Pass is one of the oldest services in Azure
15:25
It has been released for over 10 years now. And they only have lost seven messages throughout all those years
15:35
Can you imagine how good is that? Like, I guess they have had trillions of messages delivered
15:40
and they only have missed seven. I mean, that's one thing they can brag about
15:48
Fair enough. And, of course, some details. There are various tiers in that service
15:56
There's the basic tier, or I think it's called classic. No, I think it's called basic, actually
16:03
And this is the cheapest one. Actually, it's free until a number of messages
16:08
but it is totally not recommended for use other than development and testing
16:14
We have the standard tier, which is more modern, more trustworthy, but still not recommended for production
16:26
If you do solutions in production, then Microsoft recommends using the premium tier
16:33
which is a bit more expensive. In the other tiers, you pay for as much as you use
16:40
when in the premium tier, you have a fixed price, and then you can pay more than that if you break some limits
16:47
which are pretty much unbreakable. Then there are some quotas as well
16:53
The maximum message size can be up to 256 kilobytes for the standard tier or 100 megabytes from the premium tier
17:03
The queue or the topic size can be between 1 or 5 gigabytes from the standard tier and 80 gigabytes from the premium tier
17:12
And if you're wondering how can the queue grow, well, as I mentioned before, ServiceBus is used to decouple applications
17:22
So the sender may send as many messages as they want, but it doesn't mean that the messages will be picked immediately
17:28
So you have to put those messages somewhere, and that somewhere is storage, kind of storage, and this can grow, grow, grow up to a limit
17:38
So this is what that limit is. And since we're talking about JSON messages
17:43
and not images or stuff like that, or messages of 256 kilobytes
17:50
we have a pretty huge number of messages that can stay in the queue or in the topic
17:56
before it starts to become a problem. Another limit is that you can only set up to 100 messages
18:05
100 messages per transaction. And this stands both for synchronous and asynchronous communication
18:14
And that you can have maximum 10,000 topics or queues per namespace. Namespace is actually a
18:23
grouping term. And when you create an Azure service bus instance in your Azure account in
18:31
your research group then what you create in essence is a namespace an azure service pass
18:36
namespace there of course there are more you can find all of them in microsoft documentation
18:47
other interesting features about service pass is that it is one of the most interconnected services
18:55
in Azure. It works very well with Event Grid, with Logic Apps, with Azure Functions, Power Platform
19:03
Dynamics 365, Azure Stream ytics. For those of you who work with IoT, this is a very important
19:10
one. And if you don't have any one of them, or if you are trying to send messages or pick messages
19:17
from outside of Azure, then Azure Service even exposes an API, a RESTful API which you can use
19:27
you can consume and send messages that way. So it isn't only available and optimized
19:36
and interconnected with all those services and even more than those in Azure
19:41
but it is even available from whatever kind of application you have
19:47
You can use a number of SDKs to send messages to Service Bus, including, but not limited to C Sharp, Java, C, EURC++, Python, PHP, Go, JavaScript, and even more
20:03
Of course, it is fully managed by Microsoft. And we should not underestimate that one because there are a lot of message brokers
20:12
but if you try to set up one by yourself and if you try to manage it and to host it
20:16
and to keep it alive and scale and parallelized, then you will see that it is a huge pain
20:24
And having Microsoft manage it for us saves us from a lot of headaches
20:32
And as I mentioned earlier, Microsoft are very proud about this product
20:37
They see it as an industry-leading, when it comes to reliability and availability
20:45
And you understand that if you're going on an architecture where you put a middleman to decouple applications
20:52
then you are actually implying that the applications might be shut down
20:58
whenever possible, and it's no worries, because the middleman is going to be up and running
21:04
So it takes a lot to build the trust, and it takes a little to lose it
21:08
and Microsoft and Azure have succeeded to create a product that is considered to be one of the most reliable and available products in this area of the market
21:20
Further on, as I mentioned previously in the agenda, I wonder myself and I also hear this
21:30
question a lot, what is the difference between Service Bus, Event Hub and Event Grid
21:37
And those three services together consist the services that Azure offers when it comes
21:46
to message driven architectures. So starting from the right side of the grid, we see that the event grid is the one that
21:55
is most different from the others. Because while Service Bus and Event Hub use the sender subscriber model, the event grid
22:06
is using the push style distribution model, which means that the event grid will see that
22:13
message gets delivered to its recipient while the other two only um make sure that the message is
22:22
delivered to service bus and that it is i sorry that it is picked by the subscribers so why don you use Event Grid Well if you want to react on something
22:35
and if you want to make sure that something will happen, then I suggest you use the Event Grid
22:42
So the Event Grid is also used quite a lot by Microsoft itself
22:48
Example-wise, for Azure Function triggers, Event Grid is what triggers functions and other similar stuff
22:59
And it is used to send discrete events. You cannot accumulate them and you cannot aggregate them in any way
23:08
They have to be completely autonomous and they have to be sent and intended to be processed by themselves
23:18
Then we have the event hub, which is the one solution you should use if you have high volumes
23:26
of data. And this is why I don't have the IoT hub in this slide. But it is very, very similar to
23:33
event hub. And it also is designed to be able to receive and process many, many messages
23:42
a high volume of messages, millions of messages per second, is no problem at all for the event
23:48
hub but the difference here again is that the event hub will receive a message and it will not
23:55
send it somewhere else but it will wait until the message is picked by the one who is interested in
24:01
picking it and it offers features like re-reading messages like you don't have to to mark a message
24:10
as processed when it is processed it can be re-read again and again and again and this is a very
24:15
useful feature if you are building, like if you use another Stream ytics job, and
24:24
during the time that you're configuring it, and you want to stream the same messages again
24:29
and again and again. And this is not always an option. So you can ask the Stream ytics job to go back in time and reread the messages that
24:40
were sent an hour ago or something like that. So you would use the event hub to react on something that has happened, like a sensor sending temperatures, and we monitor all of them, and we react to when the temperature gets over 40 degrees or something like that
25:03
And we can also use the event hub to aggregate messages and like to take the average temperature or something per hour
25:14
Then event hub would be a very good solution. Or if you want to do anomaly detection and to perform an action like that, then you have to check a lot of messages in the same time
25:27
And last but not least in the topic of the day, the service bus
25:31
this is also different very different from Eventbrite and quite different from Eventhub
25:38
it can also get a high volume of messages I would say that the biggest difference
25:46
between the Service Bus and the Eventhub is that the one is getting events
25:51
and the other is getting messages and okay well they are kind of
25:56
similar but I would say that a message is an event with body like it contains information inside of it uh technically the event can also
26:08
contain some information but we should treat events as discrete as um as entities of their
26:14
own and we shouldn't care about um information inside them uh the events should be like this
26:20
happened this happened this happened while a message can contain information about exactly
26:25
what happened. So you could use the service pass to create a new task, like if an order is created
26:35
and you have to ship it. Or if, I don't know, if time goes and you have to create a log or something
26:45
Those are scenarios where the service pass is going to be very, very useful. And as I mentioned
26:51
in the beginning. It has queues and topics and it follows the send and push methods. The
27:00
sentence or subscribe methods. So you don't have recipients, you have subscribers. And we also
27:09
I guess it's a good time to mention another important feature of the topics, which is that
27:17
the topic one topic can have multiple subscribers and if you send one message to one topic then it
27:25
will be delivered in each subscription so it's not like that that then you have one topic and
27:31
10 subscribers and the first one who picks it is the one who keeps it with them instead it is going
27:39
to be like that that every subscriber is going to pick the message for themselves they're going to
27:45
process it from themselves and so on so forth. So summarizing you use a service bus to
27:53
to decouple application and to react if there's a new task or something
27:59
You're using the event hub to react on something that is happening and you're using the event grid
28:06
to ask the recipient to do something. Going forward with the architecture
28:15
As I mentioned earlier, the Service Pass is very well interconnected with multiple other
28:24
Azure resources. So as we can see in this slide, I have created an imaginary architecture where I have a storage
28:34
account containing files, maybe containers or blobs, and then another function is triggered
28:42
by a blob being created and it is sending a message, you see the message here, to the service bus
28:49
and then you have another Azure function which picks that message because it has a subscription
28:57
on the same topic where the first function sends its message. It picks the message and it saves it
29:04
in another storage account. Or another scenario, we have a logic app which is executed
29:10
which is triggered by something, maybe an HTTP request or something like that
29:17
It gets the request body, it puts it inside a message, it sends it to the service bus
29:24
and when the other function picks the service bus, and I guess I should mention that there is a specific trigger
29:33
for Azure functions to pick messages, then it picks the message, it processes it
29:40
and it sends it farther on to the data factory. And last but not least, one which I use quite a lot
29:51
as I will show later on also, is the API management, which gets a request to an API endpoint
29:59
This is the request body in the facility language and it is using the API that Service Bus exposes to create a message and send it using a post request
30:12
It acts as a usual restful API. There's no difference at all
30:19
And by getting the response back from the Service Bus, you do know if the message was sent or if something was wrong
30:28
example wise in the standard tier there is no guarantee about or it's not a matter of guarantee
30:36
they you do know that you might have slight interruptions or a bit higher latency sometimes
30:44
and you have to take care of that so by checking the response of the api you know if the message
30:51
was delivered or not and in many cases you have to try again later or you have to try resending it
30:58
and so on so forth but in any way the application the api management is sending a message using the
31:05
api and another function is picking that message and is doing something appropriate let's uh
31:16
so now an example of a real application uh which i do as a hobby project we do have let's say that
31:27
that I have built an application and native application using Maui. And this application is sending a request
31:36
to API management, a main point there. And then this itself calls the backend Azure function
31:45
which processes the body and creates a message. And it is sending, it sends a message to a service bus topic
31:54
Then I have three functions and the web application who are picking, which are picking those messages using their own subscriptions
32:05
So the first function has subscription one. The second has subscription two
32:13
The third has subscription three. And the web application has subscription four
32:19
So all of them are picking the same message. One is sending it to Postgres database
32:26
The other one is creating a file in the file explorer. The third one is sending it to an AI model
32:34
to perform anomaly detection or something like that. And the web application is displaying the message to the user
32:44
So as you can see, what would happen if we didn't have
32:48
the service bus in the middle is that that Azure function will be responsible to sending the
32:55
message first to this, then to that, then to that, and then to that. And if that is down
33:02
then nothing works. Or if that is down, then the message is never saved in Postgres, or it is never
33:09
saved in the file structure. Or in every case, if one integration is down, then it doesn't work at
33:17
all. When we have the service bus in the middle, then we have the luxury of waiting for the
33:25
application to react, to come alive again, and to be able to process the message. Also, if the
33:35
sender is down, then this doesn't mean that the subscribers cannot pick messages and continue
33:42
working. So it is a win-win. We have successfully decoupled the application by putting the service
33:50
bus in the middle. I think that now it is a good time to do a small demo. I will leave this QR code
34:03
in the screen for a few seconds. Let's say like 10-15 seconds. And please take a program on mobile
34:10
phones use the camera and scan it don't worry it will only get you to another function and you will
34:17
get a message i am also going to do it myself to make sure it works first at all but even
34:26
to create some messages very good and i hope some people have done it by now and let me show you some
34:35
code. Okay, so what you just did by scanning the QR code and by getting to the website
34:48
or actually it's not a website, it's a URL which sent you some text as response, is that you called
34:56
an Azure function which I have published in Azure, and it looks like that. I will try to zoom in a
35:03
a little bit to make it easier to read. So that's the one, it got a get request
35:11
And from the body, actually, it didn't care at all about the body, it generated the random funny name
35:18
If you refresh the your browser, then you get another random name
35:25
Then I got the connections with the service bus from my local settings
35:31
And then I have the topic name. I create a client to be able to talk to the service bus
35:38
And this is coming directly from the SDK. So this is the way Azure functions are interconnected
35:45
to the service bus. I created a sender using the client. I created a message by converting the text to bytes
35:56
And last but not least, I use the asynchronous method to send the message
36:01
to the service bus and I gave you the response with the friendly message you read
36:06
Thanks a lot for attending my session, random funny name, let's hope it works
36:12
So this was one function, the one that sent the message and I have written another one
36:19
the one which is called subscriber, which is responsible for picking the message
36:25
and printing it on my screen. Now, as you can see, the function is not running
36:33
but we still were able to send the messages. So exactly what I mentioned earlier
36:39
we don't have to worry for both systems being up and running
36:44
It's enough that one of them is, and then the service bus is going to keep the message for us
36:49
while the other one is getting ready. So let's see what happens
36:53
if I go to my Service Bus namespace, as you can see, I will go out to the research group
37:04
And here I have created a Service Bus namespace. And it has a couple of topics. Actually only one
37:11
the one that is called default. Inside of it, I have some subscriptions
37:18
which is called default as well. And if I use the Service Pass Explorer
37:27
and it loading and I have to select the default subscription the one I mentioned earlier then I can see that I have seven messages waiting
37:36
Now I am in pick mode. Being in pick mode means that you can see the message, but you do not mark it as completed
37:44
If I were in receive mode and I got the messages, then they will disappear because you can only pick them once
37:52
once per subscription, of course. So let's stay in pick mode and pick the messages from start
38:01
And as you can see, I say my numbers here. And if I click on one of them, then I see the funny name
38:08
that was automatically generate a legitated Bratton or sleepy Jennings or jovial summit or pensive more mortal
38:18
or something like that. So what I expect to happen when I run my subscriber function
38:27
which as you can see has a service bus trigger, listening on this topic and using this subscription
38:36
and the connection string that comes from, I can show that I will delete everything later
38:44
So there is no worry. As you can see, I get the connection string from the settings
38:50
Then I am going to pick this message and I'm going to display it on my console
38:59
So if I run this, let's see what happens. I expect it to react
39:08
immediately and it does. I maximize the window. Maybe I can even make the text a little bit bigger
39:15
And as you can see, all the messages that we had in the service bus are now being displayed
39:23
So if I go back to Azure to the Explorer and refresh
39:29
then now we have none. And I will try to move this here
39:33
to show you how quick this thing is. And this is the function that you have been calling
39:38
So if I call it again, and as you see, jolly yellow or something, and it appears directly here
39:47
If I refresh again and again and again and again, then the moment the subscriber picks the message
39:57
oh, I guess someone, oh, I had another function that keeps the whole thing alive
40:03
The moment someone sends a message, the subscriber is picking it. So this is how fast the things are done
40:10
And let's close it again and generate a couple of messages again
40:17
As you can see, there is a couple of those. Now, if I go back to my subscription
40:24
and I pick from start, then I can see that there are still messages here
40:30
So this was a small demo I had for you today. And I did show you some code, but you need more than that
40:40
I did show you how to create a sender and the client
40:44
and how to send the message, but there is way more than that
40:48
You have to react on the response that you get from Service Bus
40:52
and you have to do other stuff. You have to retry, you have to abandon
40:57
or you have to send the message to the dead letter queue if you cannot pick it or if you cannot process it
41:03
and information about all of those techniques is going to be found in Jonah's book
41:11
Jonah, in the emails I could find in the GitHub repo, I found this cute bird
41:16
You mentioned that it's going to be another animal, so don't take this for granted
41:21
You might see another animal when the book comes out. I'm very, very curious to find what it is
41:27
But what I wanted to mention is that there's going to be actually a whole chapter
41:31
or a whole section about Service Pass. And if you want to learn more about it
41:36
and if you want to know all the tricks and tricks, then don't miss the opportunity to get and read that book
41:46
Going further on, the first in-first out pattern, which can be implemented using Azure Service Pass
41:58
First of all, what is this pattern? obviously you send a message and you want it to be delivered first and you send another one and
42:06
you want it to be delivered second well how do you do it there is one term called session
42:13
which you can put it in a topic or in a subscription and you have to implement it in your
42:18
message of course and by putting session ids like you see in this image we have the session one two
42:24
three, two, one, and so on and so forth, then Service Pass is putting the messages in order
42:30
so that the messages are delivered in the order that they are received
42:35
Then I do have to mention one little trick here, which is the idempotence, meaning that the messages
42:45
can be delivered multiple times and they can be picked by multiple subscribers, meaning that
42:54
If you have database operations and you do an insert and delete
43:01
and the first agent picks the insert and the other agent picks the delete
43:05
then obviously you have an issue. So you have to make sure if you're using multiple subscribers
43:13
using the same subscription, that you have to make sure that only one of those picks the message
43:20
Or maybe you should rethink if you do want to implement the first-in-first-out pattern at all
43:28
I have another QR code here. By scanning it, you get to Microsoft Learn and information about this and even more patterns
43:38
and how to implement them using the service pass. Oh, I also wanted to talk to you about the scheduled message deliveries
43:49
because the SDK offers us two ways to send messages and then to be delivered exactly when we need
43:58
So the first one is to set a value in the field called
44:03
scheduled and queue time in VPC. And the other one is to pass both the message
44:08
and the scheduled time via the schedule message API. I will show you very, very quickly in Visual Studio
44:17
how to do both of them. So the first way, sorry, the first way using the scheduled
44:24
in queue time field is by, and I will zoom even more actually
44:30
by putting a daytime object here, daytime offset. So in this case, I have now plus, let's make it five seconds
44:40
And I will run this thing. And now what I expect to happen
44:52
Okay let see Let put this one here Oh I see I had some messages while I was doing That good So if I go back and I call the sender this time
45:08
then as you can see, it will wait five seconds before giving me the message
45:13
So let's call this one. And tender raman, it's called. Five seconds later, here it is
45:22
Let's take another one. Prickly Almeida, five seconds later, here it is
45:30
Okay, five seconds is very short time, but this is how you, it wasn't showing very well
45:36
but this is how you do it. I don't want to waste a lot of time
45:40
And to implement the second way with the other API, you just called instead of
45:48
instead of send message async, then you called schedule message async, sending the message and the date time. Now, the hours, for example, now this will be sent
46:03
this will be sent immediately, but it will be available one hour from now
46:10
Come back to the presentation. And close to the end. I want to say a few words about the dead
46:19
letter Q. This is a special Q which is available in the service bus and it is used to receive the
46:28
messages who were not able to be processed by the subscribers. And there is
46:36
multiple reasons why a message can get there. First of all, it could be too big so that the
46:43
header size is exceeded. As I mentioned earlier, there is a limit about how big messages can be
46:49
So if it becomes too big, then it cannot be processed anymore and it's moved to the dead
46:54
letter queue. Another reason is that the time to leave option can expire. There is a feature
47:00
in the in all messages called time to leave and it has a default
47:07
value as well. And when this time is passed, then the message is considered to be expired
47:13
and it's not available for pickup anymore. Then if you configure your topic as a session demanding one
47:22
and you send a message without a session ID, then it will automatically be moved to the dead letter queue
47:31
There is also a limit about how many hops a message can take
47:36
between subscriptions. So if you jump for more than four times, then you get into the dead letter queue
47:45
and this is to avoid circular references. And there is also a max delivery count
47:51
which can be configured. And if this is exceeded, then again, the message gets to the dead letter queue
47:58
Last but not least, a few pitfalls I have fallen into and I would like to recommend that people avoid
48:07
is that if you're using the API, you should be aware that there are connection limits
48:13
There is a number of messages you can send per minute. And if you exceed that
48:17
then you will have to wait for the minute to pass before sending new messages
48:22
And this applies to the connectors available for between the service bus and other services
48:29
such as the logic apps, example wise. So keep in mind that you're not free
48:37
to bomb the service bus as much as you want. You have to be smart
48:42
and you have to configure your application so that we don't break those limits. Otherwise you're going to have bottlenecks
48:48
Another issue is that there is no emulator yet. It has been reported to Microsoft
48:55
that there is a need of it, but to be honest, I feel that I need it
49:03
because I don't want to be dependent having another subscription all the time if i had one i would use it a lot and i i guess that
49:11
the reason the reason one is that the service bus is being is evolving all the time and they don't
49:17
have their the ability or the time or maybe they don't see a lot of value in it in creating an
49:23
emulator because if they make one they want it to work good and to reflect the service bus that
49:29
really exists. Another risk of course you find it out directly is that you can only set text
49:35
no media, and to know what you're thinking that you can convert an image to a base 64 string
49:42
but be very very careful with what you're doing because those strings can be really really big
49:49
Then of course it is a single point of failure if you use it in your architecture in that way
49:55
So it is very reliable. It is, let's say, always available, but it's still, it is a service
50:04
which is somewhere and if it fails, then most things fail. So you have to be aware of what
50:12
you're doing and you have to make the disaster recovery plans and you have to think of what
50:18
happens if for some reason service bus is not available if you need no low latency then you have
50:27
to use the premium version of service bus i know it costs more but if you do have the need then
50:33
low latency is guaranteed there you get low latency even with a standard version of the service bus
50:39
but there is no guarantees and in my experience um pretty much every day or every couple of days
50:47
you will get like half an hour or a quarter of an hour of bad latency of a bit higher latency and
50:56
I'm not talking about minutes I'm talking about seconds but if your application needs to be
51:02
instant then you have to go with the premium one and last but not least and I avoided to show you
51:12
how I connect the service bus. The service bus offers you shared access keys if you want to use
51:20
them. I know it makes things simple. I know it is easy, but it is not safe because a shared access
51:30
key can easily be committed to Git. It can easily leak somewhere and you can lose it and then
51:37
you have security issues. So what you should do instead is that you should use the managed
51:44
identities and role based access control. So there are roles for Service Bus such as Service Bus
51:52
Data Sender or Service Bus Data Owner which can do more of course or the receiver and use all
52:00
those roles apply minimum rights so give to your applications only what they need not everything
52:09
not all access only the access they need to be able to perform actions with the service bus and
52:16
with those words I would like to thank you a lot for attending my session thank you for being a
52:23
member of this community and Jonah and Holcom thanks for inviting me I had fun I hope you had it too
52:36
Yes, thank you. Thank you so much, Nikos. It was a really great session. Yes, it was great
52:42
Thank you so much. I like the way you talk because it's like you
52:47
it feels like you're in an ambient environment. Yes, thank you so much
52:54
Yeah, thank you. Great session. I learned a lot about Azure Service Bus and I'm sure our audience as well. We do have questions, Håkan and Nikos
53:05
Oh, fantastic. Yes. Do you want to ask the first question, Håkan? Yeah, sure. So we have a question from Adedulapo, Ocon, Sanmi. He says, I currently use Azure Redis for catching MSHQ. Would Service Bus be a better implementation
53:21
and it also clarifies that the red this is front of a database
53:28
um it depends um it could be used instead of redis well redis is actually
53:36
it's some kind of memory so you use a dictionary uh style of let's call it the database
53:44
which has very fast writes and very fast reads. And if you have that needs and ready suits you
53:51
then sure, go for it. Then it depends a lot on the volume of messages you have
53:58
And if you want to optimize your costs, then keep in mind that Service Pass
54:02
will give you 1 million of transactions for free every month. That's quite a lot
54:08
So if you have lower than that, then you can bring your costs to zero, like totally zero
54:14
So, yeah, it depends a lot on what you're doing exactly. But it could be an option, absolutely
54:24
Okay, great. We have a next question here. Thank you for answering, Nico
54:30
So next question from Aman Basiston. Hi, if a topic, for example, has two subscribers
54:39
now let's say if the first subscriber received the message, then the second subscriber cannot get the message what to do so both can process the message
54:50
well you cannot do anything because this is not you do not have to do anything because this is not
54:56
the case if you you send the message to a topic and then every subscription will get a copy of
55:03
this message by default you do not have to to configure it somehow this is how it works out of
55:10
box. What you can do is that you can filter out some messages, because what is more likely to
55:16
happen is that you're going to have some subscriptions that are not interested in some
55:21
messages. And I didn't mention it, but every message can have metadata and custom data
55:29
And you can use like a type message type thing or something. And to call it a message type, I don't
55:35
know an order and then that subscription that is listening and that it is expecting to pick messages
55:41
which are kind of orders are going to pick those messages and if you get a message with another
55:47
type then that specific subscription is not going to pick it but if you don't use any filters then
55:54
every subscription is going to pick every message when i do implementations i always have one
56:01
subscription called verbose without filters. So what this does is that it picks every single message
56:08
And I have like a maximum time to leave for the message like in three hours or so
56:14
so that it doesn't get over over flooded. But the other subscription also get copies of the
56:21
message if they want them to. So in your questions, in your question, you don't have to do anything
56:27
Every subscription is going to get a copy of the message unless you want something else
56:34
Okay. Yes, thank you so much for that. I have one question
56:40
I didn't post it in the chat, but my question is, let's just say we have someone in our audience or watchers right now that are new to Azure and still starting to learn about Azure Service Buzz
56:53
What is your practical advice as a developer and architect to get started and really try to understand the basics of this to develop with Service Bus
57:06
Yes. Well, first of all, I would advise you to understand the message-driven architecture
57:14
Most of us who design software and who design software for cloud are used to build microservices
57:21
and the microservices most times talk directly to each other so if you have a database microservice
57:29
then all the other services are going to consume the database as a microservice directly without
57:36
anything in the middle. When you have to start issues with some of those services then this is
57:43
when you need the service bus or another kind of message broker and how you get started well
57:49
it's not that hard actually Microsoft has perfect documentation and also once again
57:59
Jonah's book is going to be a good way to start learning about
58:04
Service Bus as well as other resources Yes, you're selling a bit about my book
58:11
It's like my co-author I have read some I have read some
58:18
and I wish that I had read it earlier. Yes, that's right
58:23
Yes. So I also have a question, Nikos. So what if you just want to try it out
58:29
Do they have like a free tier that you can try and what are the regular costs
58:33
if you use it in a more real world scenario? Absolutely. The basic tier is completely free
58:41
but you only get a specific amount of measures. I don't have the number in my mind
58:46
but it's a it's a quite big one also it's more a matter of reliability that the free tier the basic
58:54
tier is not going to be reliable at all so you will have issues when you send your messages and
58:59
they are not received or stuff like that then the standard year will also give you a very big amount
59:06
of a number of messages for free to to to pick and to send but after after some millions of messages
59:18
then you do pay something very very little it's not the cost that will make you move to the premium
59:25
tier it's the need for low latency and high availability in my solutions i am i'm completely
59:33
fine with the standard tier and we have in one specific project like one and a half million
59:42
messages a day and the bill doesn't get higher than 10 crowns swedish crowns per month that's
59:49
like one dollar per month if we had the premium tier then it would cost 6.99 per month that's
59:57
that's a big difference but then we do have issues with the latency and we do have issues with the service bus not being available for very
1:00:05
very short periods of time. And we handle those issues by coding the solution to retry again and
1:00:13
again and again, until the service bus has been available again. So it's a matter of where you
1:00:22
want to put the effort. If you want everything to move smoothly and no issues at all, then go for
1:00:28
the premium tier it's uh it's the one that suits you best if you can't cope with some very very
1:00:34
very little trouble then the standard tier is going to be dramatically cheaper than the premium tier
1:00:41
yeah okay great great answer thank you i think uh premium just to add i think premium tier is
1:00:48
ideal for production workloads and if you're just a beginner learning then it's more practical of
1:00:55
of course, to start the standard or the cheapest possible to say yes
1:01:02
Yeah. Absolutely. Thank you. Yes, that's right. I think we don't have any more questions, Hocan
1:01:09
Yes. And we're also at the top of the hour. But I want to share to everyone that we got feedback from Ashish
1:01:18
Great session, Nikos. Thanks, Ashish. So Amar also said, great presentation. Thanks a lot
1:01:28
Yes. You're very kind. Yes, that's right. So we do have a FICA, like a Zoom meeting for 15, 20 minutes to those who want to continue the questions or conversations with Nikos
1:01:43
So feel free to join us. Let me just send the link, the Bitly link for that Zoom link, which we will connect to later
1:01:51
After this live stream But otherwise H Do we have anything else for Nikos before we ask him to share about his upcoming events or contact details
1:02:06
No, I don't think so. I can have to show it here too. Yeah, that's practical
1:02:12
I did that actually. Great. Thank you. Thank you. All right. Nikos
1:02:19
So if our audience or your followers want to reach out to you about this topic or anything about Azure, how can they reach out to you and listen to your podcast, of course
1:02:33
Oh, thanks for asking me, Jonah. Well, I'm a very easy to find guy
1:02:39
You can find me in Twitter, LinkedIn or in my blog. actually if you scan the QR code that is
1:02:44
that I showed earlier if you did scan it then you will get to my
1:02:48
blog and get all the contact information my twitter handle is andytechnique
1:02:53
and my podcast is called azure triumphs and yeah I think you can see it right let's say
1:03:02
here that's the one and yeah just drop in line I'm very very
1:03:08
happy to speak with everyone If you have feedback, if you have questions, whatever, let's connect and let's talk
1:03:16
Okay, that's great. Thank you so much for that. So I think it's time
1:03:23
So I hope to see everyone on our after session Fika. Me too
1:03:30
Grab a coffee, guys. Yes. See you in a couple of minutes. Yes, have a great weekend, everyone
1:03:38
and enjoy the weather that we have today. Bye-bye. Bye-bye, everyone. See you next time
1:03:43
Bye

Azure User Group Sweden: Fire & Forget with Azure Service Bus

c-sharpcorner_com

Dynamics 365 Customer Insights Part 1 - Microsoft Business Application Live Show Ep. 19

Ingest Data into Azure SQL Database using SSMS

Understanding GPU's for fine-tuning GPT engines

Norwegian Bliss Alaska Cruise | 7 Day Alaska Inside Passage Cruise Tour & Experience

Master Node-Red C2-NRED Control of Click PLC I/O

Nokia G21 - How To Edit Notification Panel Shortcuts

How to Set Up Custom LED Lamp Notifications for Apps on ASUS ROG Phone 7 - NotifyBuddy App

How to Turn On Eye Comfort Mode on SAMSUNG Galaxy A53 5G // Eye Comfort Shield

How To See How Much Traffic A Website Gets? [in 2025]

Signaling Devices in Survival Kits – Do They Work?

Access and Contribute to FreeCAD Part Library | FreeCAD Tutorial | FreeCAD Part Library |

Banned Technology around the World | Tech That Got the Big "NOPE"!

Up next in 10

Azure User Group Sweden: Fire & Forget with Azure Service Bus

c-sharpcorner_com