.Net Foundation On .NET, 9 Jan 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Advanced Features with Azure Service Bus

Description

Azure Service Bus Messaging
https://docs.microsoft.com/azure/service-bus-messaging/service-bus-messaging-overview?WT.mc_id=ondotnet-c9-cephilli

Compare Azure Messaging Services https://docs.microsoft.com/en-us/azure/event-grid/compare-messaging-services?WT.mc_id=ondotnet-c9-cephilli

Azure Service Bus .NET Client
https://github.com/Azure/azure-sdk-for-net/tree/master/sdk/servicebus/Microsoft.Azure.ServiceBus

Azure Service Bus Samples
https://github.com/Azure/azure-service-bus

Cloud messaging patterns
https://docs.microsoft.com/en-us/azure/architecture/patterns/category/messaging?WT.mc_id=ondotnet-c9-cephilli

AMQP https://www.amqp.org/
In this episode, Ashish Chhabria joins Cecil to talk about some of the more advanced features of Azure Service Bus. They’ll cover topics such as scheduling, differed messages, duplicate detection, disaster recovery and more!

[00:37] - Using sessions
[04:46] - Auto Forwarding
[07:24] - Scheduling messages
[09:00] - Deferred messages
[13:17] - Duplicate detection
[16:00] - High availability and disaster recovery
[22:49] - Security features for Azure Service Bus

#dotnet #azureservicebus #dotnetcore

A

The.Net Compton is bringing to you a dotnet, calm, focus event on January 14 to 2020. That's all about building web apps with blazer. This will be a free one day. Livestream event that features speakers from the community and also the dotnet product teams, make sure to tune in to focus dot, dot, net comp net and come see what all the excitement is about. Ask questions live and get some deep training on how to build beautiful, interactive and powerful web UI with blazer.

A

In this episode of the are not night show, we will have yet another video where we're gonna talk about as your service post and this time we're gonna dive really deep in some really advanced features that might be great for some of our enterprise customers.

A

Everyone welcome to another episode of the are not nacho, and today we're gonna continue our conversation about as your servers boss, I'm going to dive deeper into some of the more advanced features that are available in the service. So please tell me: what are we gonna talk about next perfect.

B

So yeah, let's talk about all the enterprise and advanced features that service offers and let's start with something that a lot of customers have been asking for and and we have we've built quite some time back. Actually, okay, so lots of customers have asked for hey. Can we do FIFO?

B

If you know first and first up with service bus and we always say hey service bus is ordered and received by default, but we don't make ordering guarantees unless you use sessions- oh yeah yeah, so so we do have that functionality built in and what that allows you do is is to group these messages that may be related to each other mmm by setting a session ID on them. Okay, and as long as they have the same session ID they be grouped together and then you can lock the session itself right. Okay,.

A

B

Way it works is let's look at this, so let's say the sender sends a bunch of messages. You know the blue ones and the light green ones are different sessions. They have different session IDs. Sure.

C

B

That's the s1 and the s2 right and the sender has set these on the on the you know. As a.

A

B

And the message yeah what it's actually doing on the back end, it's actually creating two virtual queues right, one with session ID equal to one and the other one with session ID equal to two yep right and now, when the receiver comes in the receiver can no longer say I want to be o'clock on a message. It has to say- or you know message handler, it has to say on a p-block on the session itself. Yeah.

C

B

Means the entire session is now blocked by the receiver yeah.

C

B

Now, since we have, you know, blocked it and it's an order, the receiver can start processing these messages in order, one after the.

D

B

So that's pretty straightforward: it allows them. You know the session acts as a as a virtual queue on top of the queue itself, and you know as long as you lock the entire session that that session is not visible to anybody else.

A

So it's locked to a specific receiver. Yes, and it's also ordered right, so the receivers should know. Hey I'm, expecting like this sequential set.

B

Of messages to come in that's great yeah, so sessions can be long-running. It's not like as a start session and a stop session on the sender side use that you just set the message ID or the session ID yeah.

C

B

What you want the session to be, and that just keeps your session running yeah.

D

B

Say you know the future, the receiver, the first receiver, that the one that's the dog, blue or the gray wants to hold on to that session. They can potentially hold on to that session, ID and say yeah. If this you know, I'm gonna lock the session and only process it if the session ID is this okay, so you can ensure that the same session goes to the same receiver or at any point in time. A single session is processed by a single receiver right.

A

So it's almost like Hoekstra for me, I'm very familiar with the web world mm-hmm in the web world. That sounds like what we call sticky sessions right like when we.

D

Hit a load balancer right.

A

And we just want to make sure that we hit the same server every time whenever we send our messages.

B

It's kind of similar to that right, we're hitting.

A

The same receiver, right on on the server's, both side, you know once we lock that particular session. That's great.

B

So a very quick example: it's pretty straightforward! All you do over here is set the session ID, so I mean I just created two session IDs at random and.

C

B

Just plug those into the messages and at random as well, and then on the receiver side. You know we saw the receive or register message handler earlier. Yeah.

C

B

We have the register session Handler instead got it and the way it works now is that you're locking the entire thing and then processing the message one after the other, but it's still a session lock, I, don't.

A

Know a message lock so then the receiver side needs to know that it's particularly looking for sessions that.

B

Is right, you got it okay, and, and actually it's more it's you know it's more management oriented operation than that when you define a queue or a subscription, you have to essentially check a box that says enabled sessions. Okay, so.

C

B

Once you have sessions enabled you cannot just send regular messages on to it. Oh.

A

Has to be sessions only for that particular queue that you're sorry got it. Okay,.

B

I mean you could, in theory, have a single session or a session of the single message to make the same behavior but remember sessions are slightly more computationally intensive, yeah.

C

B

Know because you need to keep them grouped together and make sure they're in order, so make sure you only use it when you want to group these messages together and lock it on a per.

A

Session level cutter that makes sense.

B

So let's move along and let's look at order forwarding right now you know you could you could forward messages from from one queue to another queue or not.

C

B

By writing an application that reads from one end and then pushes it out to the other. But we want to make that easy for you, so you can set up auto forwarding from a queue to a topic or a queue to another queue.

D

B

Within the service bus broker itself, yeah.

C

B

The way it works is that you know multiple patterns can leverage this. Let's say your sender queue is acting as a send buffer and the receiver queues acting as a receive buffer. You want to decouple it even further. Yeah.

C

B

You could have a send queue that automatically falls to the receive queue so.

C

D

B

Have to worry about, you know essentially having the queue depth increase on the send side. Just because the receivers are slowing down got away. You could also scale out individual topics. So currently we have a limit of two thousand subscriptions per topic, but there might be cases if you need to fan out even further. You.

C

B

Then you could have your subscription forward to a topic and then find out from there.

A

That's interesting so now I think between that one, our ability to specify rules.

D

A

Have like a really interesting pipeline that we could create in terms of like how do we route west edges and like where do they go? That's.

B

Exactly right, I mean it even works with like different silos and in the same hardware, and you know each has their own key to read from, and you.

C

B

Know you know you want to keep configuration kind of clean in that for sure, so you can have forwarding parts and set up pipe lines like you mentioned, awesome, awesome, nice, so so the way works in this case is that you can. You know your sender seems to the queue as expected and.

D

Then the queue automatically.

B

Forwards it in one in one shot, got it the queue. One in this case will not have any depth, because it immediately follows.

A

Its sole purpose is just to like distribute also just to other folks. That's.

B

Right again, simple code sample over here. These are all management client operations, so you instantiate, the management client create the destination queue first, because you need to have something to forward to yeah.

C

B

Once the destination queue is created, then you can add the forward to destination in your source queues. You know description and then go and create the source queue. Okay,.

A

Now you're showing us these management samples inside of using.net code right.

D

A

But could I also use something like the portal or as your CLI? It's not less.

B

Apply these rules to absolutely yes, the same semantics work or the same workflow box of there as well. You first create the destination q yeah. Then you set up the source q and you can have a forward to parameter that you can set yeah.

C

B

That's all available, there's also arm templates, so any kind of powershell CLA there's.

A

20 different options for this yeah, so your DevOps.

B

Pipeline will be will be very happy as well. Nice, okay,.

A

Perfect, alright! So what's the next one we got to talk about so.

B

Next one is, you know the shared messages now we, you know there are times where the sender wants to control the narrative of how the processing should happen and when it should happen, sure, and and that's when you can essentially shared you. These messages yeah.

C

B

What that means is that the sender simply says: hey I, want this I'm, sending this message to you now, but the receiver should only be able to see it after a point in time. It could be a specific date in the future. It could be five days or five minutes from now, etc. Now and and that's something that the sender can control yeah.

C

B

The message is immediately, you know accepted by service versus as accepted as expected, and then it'll only show up once you know to the receivers once that time has come. Yeah.

A

Got it gotta go so.

B

It just stays hidden behind the scenes in the right.

A

And I think this is for me this is actually one of the features that I've used for fair amount right, particularly like for demos or you know, I. Think I created like a like a tweet scheduler.

D

A

We do everything on Twitter well, I can I want to schedule a message right like I'll. Just you know, I'll passenger to key will set a date mm-hmm and then, whenever that happens like as your function, kicks off and then starts to do, work right right, so I think that's a great way for us like schedule things and again using the power of the clouds like just power like whatever that workflow is yeah and.

B

It fits in with the goal of essentially simplifying your programming model to say, hey, my sender came back on. It's all. It's all good! You know, I'm gonna just send this message and now it's you know a pass responsibility to worry about. You know pushing it out there to the receivers at a certain point of time right right, yes, awesome! So what? If you want to control the narrative on the receiver side right.

A

That's a good question yeah, so so.

B

That's that's a different feature as well. Now, in this case, that's a deferred message. Right happens in this cases that say your receiver decided to lock the message, and you know it starts processing it, but something is not ready yet.

C

D

B

Is a reference data or database that you're looking at and you're expecting the data to be there, but it's not there and you want to get back to this message. It has to be you, but you want to get back to the message at some point in the future right, so we can say you know what, let's, let's have the receiver lock it, but at the same time the receiver says: okay, I'm gonna defer it, so I can revisit it later now.

B

How it does that is, is that the receiver gets the sequence number of the message and it holds on to it. Okay,.

C

B

That is very important because if you lose the sequence number you'll lose the message. Well,.

C

B

Once you defer the message, you have to query the message using the sequence number yeah.

C

B

The way it works is, you know, the sequence number is made available and the receiver says receive with the sequence number and that's when the message comes in got it.

A

So here's a question: I have so I deferred this message: I have the secret number mm-hmm? What happens if my receiver dies so.

B

At that point, you will have to persist the the sequence number on.

A

Here and put it in a database or Azure, storage or and I think yeah.

B

And that's exactly the pattern that most customers use because yeah they were just plugging into a database and have you know retrieved that when needed, it's a it's, a well managed workflow. So it's something you you code for not yeah! No, no! No! You know not a byproduct of yeah.

C

B

That we provide got.

A

It well that kind of makes sense for because you might want to, depending on how your your receivers scale up.

D

A

Right right, you might want to have a little bit more control over like who.

C

A

Be the person that, like that's.

B

A

B

That's great, and- and you know it could be- that this message is related to something that came in earlier or yeah.

C

B

Know if just in case you don't need sessions or there's some sort of item potency in your in your received side at that point, yes, you could leverage it from the from you know, using different messages to say yeah it'll be me who will.

C

B

Message but I will do it when the time is right, got it.

A

And so here's another question about that too. So, let's say I was not proactive and I didn't store. That message.

D

A

Store that sequence number for the message right, my receiver died. Mm-Hmm. Does that deferred message just stay there or does it expire after at a time like like what happens.

B

Yes, so it'll stay there as long as you query the message with the receive sequence number and.

D

B

Go and complete the message so it'll just say that now.

D

B

You lose the sequence number. There is a message that message is lost: mm-hmm, it's not lost in the broker. It's lost because we.

A

Receiver says: I can't go back and get it okay, all right. So it's still there that we're still like holding on to.

B

It yeah we're holding on to it it's it's potentially inaccessible. At this point, yeah.

C

B

That's something yeah I, think I think it would land up in the dead letter Q eventually.

A

Yeah yeah, but.

B

But that is something that needs to be built into the workflow to say: I'm gonna definitely persist the sequence number before deferring it right.

D

B

It's on the message property itself, so you can go ahead and it right.

A

Because I know the message properties there's a like a time to live and.

D

A

Like expiration times,.

D

A

Could specify too so.

D

A

With the combination of those right like if it's I know maybe I say, let's let.

D

A

For seven days, a.

D

A

Or whatever the case is.

D

A

After that, expiration time, they'll just go into the dead letter. Q that's right and.

C

A

We'll have some other process that I look and be like hey. What's going on here, that's right, yeah,.

B

So yeah I mean that's exactly your lap and you can. You can set the TTL and study deal expires, be moved in dead letter, Q yeah, the.

D

B

Works with with the furring is I think it pauses the the time at the time at the time of the furrow. Okay, but yeah you you get into a confusing space and most folks will not use to eat here, and then you.

C

B

Just over right on that end, okay, cool yeah, so a quick look at the code fairly straightforward. You! Basically you know in this case I'm using a list to add the deferred sequence numbers when I deferred the message you can actually go ahead and store it in the database. Like we talked about earlier yeah and then once you have stored it, you want to retrieve the message you can go ahead and say: receive deferred message, async and then.

D

C

At the sequence, number, okay,.

B

You can do that, okay, so moving along, we have now. We have the duplicate detection and in this case you know you've seen multiple. You may have browsed the web site. Where you made a payment, then you said: hey, don't refresh the page because right or don't hit.

A

The submit button once and or something like that, yeah so.

B

So that's the that's the best case best example I can give of how we you know how detection is a setup yeah.

C

B

What we want to do over here is, you know, let's say your sender sent a message mm-hmm and then failed before we send the ACK back right.

C

B

It got back up again and said: hey I need a sentence message again yeah, but now it's sending the message over and it expects that you know that the sender has no context into what happened before it crashed. So.

D

B

Idea is that, okay, what what do I expect the service bus broker to do in this case right, so it's pretty straightforward. What we do is we allow you to put you know on the queue or the subscription, a duplicate detection window. It could be up to seven days yeah. What that means is that you send the message once we lack it back to you if you did not receive the ACK or you're, not life, when you, when we send the act to you, you.

C

B

You send it back again, we would send. We will give you the act back as you would expect. If you come back from a failure. Yeah.

C

B

We will trash the copy of the message.

A

B

And I at that point with over the duplicate detection window, if you send the same message with the same message: ID, we will make sure we only have one copy yeah.

C

B

The way it works is like I mentioned, you send a message with message: ID one. We send the act back. Let's say the sender craft at this point gets back up since that the second time we send the ACK back again, but the message ID will go straight or the message the copy will go straight to the trash be sure. So we only have one copy within the duplicate detection window right.

A

Right right, so so what could happen, though, is cuz I've, seen situations where people have recreated a message to be sent right, but the.

C

D

A

Is different, but the contents of the message might be the same right.

C

A

Scenario, duplicate detection isn't immediately.

B

D

A

Fact that the IDs are different.

D

That's good, so it sounds.

A

Like it's important, that I should have some type of deterministic algorithm.

D

Or something just to.

A

Either either hold on to the message or you know, read, generates like a known message: ID rights and when I recreate it and I resend it. You know. Now the public detection can do its job right and look at the right properties and that's.

B

Exactly right and and you know, because we store everything in the binary format, it's.

C

B

Not really that straightforward to do based on the message, content, yeah, computationally and just.

C

B

General as well so yeah real loud message, ID, no, that's exactly what we we recommend. You said yeah in the deterministic fashion, like you mentioned,.

A

Yeah, that sounds pretty fair yeah. That sounds pretty fair cool. Now we got some some some more cool features to talk about right. We do yeah.

B

So so, jumping back into our enterprise mindset right. What do you and prices need? They need something that's highly available. mmm It can recover from disasters. Yeah.

C

B

That's exactly what you know we weren't provided as a service over you know all the brokers that are out there yep and and build in this cloud native environment sure so so a lot of folks may be familiar with the concept of Azure availability zones. Now this is something we offer for service bus as well, and this is a premium only feature because of the architecture of service premium. Sure.

D

But the way it.

B

Works is that on the premium and whenever you send a message- and we act it back to you- we are triple replicating by default. Yeah. Now, when you have Easy's available those three replicas live on three different data: centers, okay within the same region, so they are awful. You know we buy a few miles, but.

D

B

But there's still different data centers sure. So you know it provides. You fault tolerance within the same data center region. Right and you know when I mean you know within the same leaders in the region. Let's say one data center had any kind of you know: utility fault or.

A

Network what happened? There's a hurricane tornado well.

B

That's more of a region going down, but this is.

C

B

Localized, where.

C

B

But here's something something to that effect. When one data center is affected, then the other data centers can pick up the load yeah.

C

B

All this happens, you know all the replication within the region is synchronous, so.

C

B

Know once we have that available, it's it's totally straightforward for you, yeah.

C

B

Replication, you don't have to worry about it, there's no additional latency who is ever getting it, but the way it works is like I mentioned. We have three copies of service bus, one in each of these availability zones within the same region. One acts as a primary in the other two are secondary. Let's say if the primary goes down for whatever reason, then we would promote one of the other secondary copies to primary. Got it right, and this will happen. You know absolutely abstracted away from the sender application. So you see no issues with your.

B

You know with your applications disconnecting or reconnecting that sort just works, as is you just.

D

B

Extra availability, kind of and the fault, tolerance within the same region. Okay, so let's say you know, we already spoke of fault tolerance within the same region, but what, if you need fault tolerance? You know across different datacenter regions like your hurricane example, like you mentioned, so in that case we have the Geo disaster recovery. Now, what we currently provide is you know, D are with metadata copy, which provides you an RTO right. So let's, let's actually look at this or look at the mechanics of this. What do you do?

B

Is you essentially go to two different regions and create two different premium, namespaces yep, and then you pair them together? Okay, now, once you pair them together, we will ensure that all your metadata, so your Q's topic subscriptions rules, filters etc, are always in sync got it. So you know in that case, any of your you know, crud on your Q's topic. Subscriptions will be synchronously copied over to your secondary as well yeah, and what that means is so. This is like I mentioned, providing an RTO, a recovery time objective: okay,.

C

B

Say something goes wrong with the database with with the data center region at the time, and it doesn't really have to be a hurricane. It is a manual failover. So you differ your you pick your definition of a disaster for your okay. So for you it could be hey. My application is in life for five minutes or you know, I'm not able to connect.

A

B

Five minutes it need not be an earthquake or hurricane or something right.

A

I can I have the flexibility to define my own yeah thresholds and limits, and what no that's exactly.

B

It so yeah the thresholds limits. You have the remote in your hand, pretty much to say yeah.

C

B

Gonna do a failover, I'm gonna move from my primary to my second each other. Now, in that case, your data is not copied over, but like I mentioned it's all its metadata, only you know, but your applications will not fail with a Q, not found exception or a topic not found exception. Yeah.

C

B

So they can pick up or they can start sending and receiving from that point forward.

D

B

You know the data is not copied over right now that doesn't mean that the data is lost right, like I'm, like I said you pick your definition of a disaster. It need not be a pure earthquake or hurricane that has, since you can't destroy the disks yeah.

C

B

Know, that's that's the only case when you actually lose the data so.

D

B

A it's a fairly, well controlled environment. Your data is committed like I mentioned trouble replicated to each of these. You know copies and they're still accessible once the data center region is back online gather, but they're not copied over. So the reason we we make sure it's persisted is that you can go back. You know still access that namespace like.

D

You would and then.

B

Drain all those queues identify which ones are still valid or still needed for you, yeah.

C

B

Then you can go and start processing those messages right.

A

Onto your secondary one, so my secondary right, that's awesome. Okay, look like what you said like from a developer's perspective, like my code, doesn't really need to change really. This.

D

A

Kind of just works for me right and I just have that reliability that you know again. If something happens, and in.

B

This particular.

A

Data center right, you know, my stuff is just available somewhere else and I could just keep doing my work. That's great and and.

B

The reason it works without any kind of you know, code changes is because you know when, when you actually trigger of the failover, the connection string that you were using to point two primary yeah.

C

B

Automatically point to secondary right, and so you don't have to worry about any kind of code changes on your end. It just automatically works. The.

D

B

Of time it takes is, is under five minutes, because that's how long it takes to essentially, you know flush out the DNS entries and make it a point to secondary rather, but that's pretty much it and obviously the the expansion to this is. You know, full data copy, that's exactly what we're working towards yeah.

C

B

That's something we would like to provide the customers as well say: hey, you know it failed and I'm gonna fail over and now. Let me pick up from where I left off in terms of you know, processing the same data, so you don't have to worry about draining and replaying it. Okay. This is awesome. You.

A

Know, like I've, been using service bust personally for like a couple of years, we're like. After these conversations, we've had like.

D

A

Like I've just learned so much more about the service and more the things that we could provide, you know and I noticed tons more stuff that we haven't spoken about right security and we haven't gone into the depths and details of AMQP and like tons of other stuff. That's under there, but um I know we have Doc's top Microsoft comm. If folks want to dive in and like learn some more about that absolutely and.

B

We could add those.

A

Show notes as well. Are there any other resources that you and your team provide that you know we could send? You know our viewers to to just learn more about service buzz playing around with code or even just reach out to the team. Sure.

B

Yeah, so we do have our open-source SDKs that are available for folks to you know open issues on your contribute to. We also have open source samples available, so they're gonna have that you know on our agile service bus repository yep and they can, you know, engage with the dev team that actually builds the product and yeah a button that, like you mentioned, the Doc's are out there to talk about all of our cool stuff with security with which the network service endpoints firewall filters.

B

We have MSI on our back, so masters, identity and role based access control better and you.

D

B

To worry about connection strings anymore, or you can.

D

B

An app and tenant ID and things just work as.

D

B

Work and you can set very granular scope in terms of hey I, want to I, want this application to only write to this queue or only receive from the subscription right.

D

B

That flexibility is all built into the product as well, and.

D

B

We keep, you know, adding more more features that really.

A

B

Blog about we read.

A

B

A

Keep on there's so much.

C

Stuff going on.

B

A

Wait. Thank you again. So much I really appreciate you coming.

B

D

The show teaching.

A

Us about service bus yeah. Thank you all again for watching I hope you enjoyed this. If you have any feedback or any comments, definitely leave a comment in the in the comment section below you know share the video with your friends and your co-workers, and you know I hope you enjoyed this episode of the are not natural.

A