.Net Foundation On .NET, 2 Jan 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Azure Service Bus from the ground up

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

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, we’re joined by Ashish Chhabria who is a Program Manager on the Azure Service Bus team. He’s here to talk to us about where Service Bus fits in the Azure messaging landscape and also explain some of it’s target use cases

[00:50] - Uses cases for the Azure Messaging
[08:40] - Point to point messaging
[12:48] - Azure Service Bus Queues and Topics
[17:28] - Sending messages (Demo)
[19:34] - Azure Service Bus tiers
[22:45] - Target scenarios for the future

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 on dotnet show we're gonna learn about some of the cool features that are happening inside of Azure service bus.

A

Welcome to another episode of the on Metro, my name is social Phillip and today we're gonna be diving into one of the features in Azure that I'm a big fan of, and that is as your service bus. So with me, I have a shishu is a program manager on the team, and you got to tell us a little bit about service bus right on. So why don't we start off with you just introducing yourself a little bit and letting us know what role exactly do you play on the team, perfect hi, so.

B

Hi I'm Acharya I'm, a PM for service bus program manager and I'm part of the azure messaging team, which in which includes Azure service bus as your event hubs and as your event grid. So we essentially take care of all the messaging properties and are mainly focused on service bus. Also.

A

Yeah, so now, why don't we start off with just like a super quick introduction to.

C

A

Is as your service books I'm like what is the role that it kind of plays within that messaging, space and Azure right.

B

So so this is, you know, any kind of messaging broker helps you essentially, you know decouple your sender and receiver applications and you know essentially allow you to scale horizontally across your senders and receivers, but depends on you know, depending on your definition of a message. You can pick one of our messaging services to best fit your use case. Sure surgery depends on what do you think of you know when you think of a message, yeah sure, now, in our in our space, we essentially think of messages of two kinds we have fax in commands.

B

Okay with commands is more like a do this, or do that it's just you know when thing of a command and you're, essentially giving a directed instruction to another another person or another service to go and do something and that's where you can leverage a message broker like service bus, yeah,.

D

B

Service bus acts as a you know, as a broker that manages state transition between the sender and receiver. It works in a push and a pull model. Push on the sender side, pull on the receiver side. It acts as a central arbiter of a state. You know, and ownership between the sender and receiver applications and allows you to have rich control of any kind of communication features that you need right. So you can share your messages. You can defer messages. You can lock a message on the queue take.

D

B

Own sweet time to to process it and then go and complete it. If you know something fails, you can also go ahead and abandon it or dead letter. The message right and then have an error flow based off of that. So you can. You can leverage all of those features as well, and you know an easy way to think of service bus is use it when you know all the nouns in your in your ecosystem. So you know who is sending the message?

B

What is the message and where is it going to okay, and when you think of all these things you know it? You know service bus will fit your use case. Connor.

A

Could you give us like a really quick example sure so, let's say we use the use case of order processing as a common.

B

Use case right, like.

A

I have an e-commerce store or.

C

A

Processing or whatever, right like if I, want to put service bus in that scenario like what would be like what would my nouns being like? What would that flow rate, and it look like yeah.

B

So so you could I mean ecommerce is one of our biggest. You know customer verticals and that's you know we have done customers in that space. So the way it works is that let's say you, you walk into a website and place an order and then there's a whole bunch of processing. That's happening at the backend yeah.

D

B

This could include, you know, telling procurement to make sure or telling the warehouse folks to essentially go and pack the order. You know talk to your financial services team to essentially go and process the money, that's required for the order, mmm and all of these are directed messages to each of these teams. Sure and each of these applications and that's exactly where service bus could come in and say, and you know you could essentially trigger off a message that says hey.

B

This is the order that was placed and the warehouse team knows exactly what to do with that message. Got it so so that's one flow. You could also have it for your operations team to make sure that the customer relationship is properly maintained. You can go ahead and send it out to a mailing company, took a to essentially know when to pick up and when to ship. The archer.

C

B

All these are very directed ones, right and and you'll know more. When we talk about the next sort of messages which are facts, you know, which is more on the lines of you know, this is just a fact: do what you can with it made sure and and that's how it differs from a command command, is more directed. You know message the.

D

B

Is more like hey? Let's just let you know what's what's happening right, yeah and then you can have a bunch of applications that can act based off of that now, in the facts, ecosystem we have two times. We have a time series and we have discrete. Now we look at time series right.

B

It could be any kind of telemetry data or anything that is relying on the time series like clickstream data when a customer comes in clicks all over your website and you want to essentially track their user journey or you have a sensor out in the field. That's sending you temperature pressure and all the other good goodness yeah.

D

B

You essentially want to track for any kind of you know major changes in in the temperature, the pressure sure.

C

B

That's something you can leverage time series analysis for right. So when you have that kind of data that you need to essentially analyze, you know together, that's why you can leverage event hubs. Event. Hubs is kind of like this pseudo space, where in it behaves like a cue from the send side but from from the receive side attacks at the database. So.

A

B

Three times better for ingress than it is for egress now.

C

B

That means is that it can act as a sink for all of your message: data coming in, but at the backend you can read it like a log like a tape or you could take blobs from the backend and essentially do either near real-time processing or.

D

B

Kind of business, intelligence, offline right.

C

B

That's where event ops comes into play right, so.

A

If I understand it correctly like so, as my messages are coming into event, hubs specifically right, like I, can have this collection of facts that have come in right. Right and I can decide that I want to analyze like this particular subsection of that tape right or that cook that um that stored message set mm-hmm right and I can run analysis on it. I could do whatever, whatever the cases I want with it. But I know what service bus service bus is more of a hey like, like you said, the commands have happened.

C

A

Might happen right, I know, I'm, popping individual messages right off the queue or transactions of messages off the queue to work with, but.

D

I'm once they're gone, they're.

A

Gone right that.

B

Yeah, so so so the way it works is that you maintain cursor on your end from the client side, and you say, hey give me this message: yeah.

D

B

Gonna take my own sweet time to process it. You know I could do a whole bunch of things. I could.

C

B

Transactions I I need to. Essentially, you know, trigger off more messages based off of that that single workflow that I received and then I can go ahead and complete it, and once you do that, it's taken off of the queue okay, so.

D

B

It's it's. You know we have at least ones and at most once delivery semantics, depending on how you lock the message or how you receive from the queue. But you can leverage both of these both these ways of processing. That sounds pretty cool, yeah cool. So the next one is, you know if we have discrete events or discrete facts so to speak. It could be something like you know. A new user signed up for your service or.

D

B

Logged in from another computer and you need to essentially trigger off a whole bunch of security protocols, you.

D

B

Make sure that they cannot dedicate themselves, so these are point in time, they're not really related to an event that came in before or after them. Yeah.

D

B

That's exactly where you can use event grid. Oh okay,.

A

That totally makes sense yeah, so it's kind of like like. Is there like an instance in time like an event or a trigger, or you know you know, chefs will walk through the.

C

Door basically.

B

Like oh, we sat down in.

A

This chair right right and know if I want to kick off certain workflow based on those events right, but in now I'm not looking at this event like a collection of stuff, mm-hmm and then I'm also not sending a lot of data right.

B

Like what I kind of command rightly I wouldn't serve, it suppose, like there's, not a lot.

A

Of stuff in here this is just very small, very quick notifications.

C

A

Like something happened, let's do some work with it right, yeah.

B

So so one of the examples that I think resonates with a lot of customers is, let's say you have a smart car with like your driver profiles stored, you just walked in and you essentially click the button. You.

D

B

Now you know exactly who's in the car, so all the you know the seat, adjustments, the the driver mirrors or your cooling, climbing.

A

Things already happen, yeah, so.

B

It's like hey, I, just walked in I pushed a button, or you know someone was able to scan me potentially sure and all these things kind of happened based off of that right. So you know if, if you didn't have you know a switchboard or message broker like like it went good in that case, you know you actually have to have all these patterns laid out individually together and that's exactly what even grid is trying to solve. Yeah sure, okay, yeah.

A

B

Think of it is that there are multiple event, publishers and event handlers and the main grid kind of makes the bridge gather. Okay, cool sounds good.

A

So let's talk about some of these different patterns that we have inside of service post.

C

A

Right because again, I think service bus is probably one of the oldest right.

C

A

Know service that we have in Azure.

C

A

So it's very mature or very robust. You know and built on like that that you know that cloud scale infrastructure right, but we always talk about yeah. You.

C

A

So let's talk a little bit more about Azure service bus.

C

A

And Oh service bus is probably one of the oldest services that we've had in Azure, probably one of the first ones right right. You know, and it's built on that cloud scale, infrastructure that we always look to talk about right. So I'm really interested to hear like about some of the patterns and some of the things that we could actually do with it specifically right.

B

So some messaging as a concept has more than 50 years old. At this point and service bus is really trying to answer the question as to you know, when I moved to a shore and when I'm on Azure, what can I use to you know as an enterprise messaging service, sure sure.

C

B

Is our multi cluster offering that's? You know: battle-tested enterprise ready, high availability and geo recovery built. You know right into into the ecosystem itself, awesome right, so so from the get-go service bus. You know in terms of what it offers very basic. You know very basic semantics of point-to-point and pops up with all the enterprise speech.

B

It's going to build on top of it, okay, so very quick understanding of what exactly do we mean by 0.2 point and the way it works is that think of a sender application or a host of sender applications or multiple Center applications and multiple receiver application yeah? Now you know you don't want the receiver to block on the sender and vice versa, yeah, so you want to decouple them and allow them to scale horizontally. As as the workload increases yeah.

B

Let's say you suddenly have a spike in the number of users and you want to essentially leverage you know, service bus to essentially decouple it and act as a buffer, so that none of your customers have any kind of lag on their end. Sure.

D

B

The same time, your receivers can identify the the world hood and they could take the time to scale up right. So the way it works is that the decouples you senders and receivers in the sense to say that you know the sender would send the message to the Q and the Q will actually acknowledge this. The message yeah.

D

B

And when the Q, when service was accused, acknowledge the message or even with topics what we do is on the back end will triple replicate it. Okay, right and, and the way it works is that we will only act. The message back to you once it's replicated in our storage. Okay, so you know once once you receive the ACK, you can be sure that the data is not lost. Sure Mike, you gotta. Okay, now the Q acts as a buffer for the receiver. So you know the receivers down or it's it's processing something else. You.

D

B

Q depth will keep on increasing when the receiver is ready to accept new messages. It can go ahead and actually connect to the queue and.

C

Don't retrieve.

B

The message and then also give its act back to say that hey I completed the processing. This message you know, so you can remove it from the queue so.

A

There's acknowledgement happening on both sides right absolutely so.

B

So it's it's a reliable in system built over mqp, so on protocol level we have reliability built into it and the way it works is as I mentioned. Messages are never lost.

D

B

Long as they are act by the service, yeah.

D

B

The same time, the receiver has a control of world wants to do once it's done with the message processing, so.

A

B

Seen cases where you know obviously yeah the message is perfect: I'm done with all the processing and one complete it and removed from the queue sure their message was incorrect or wrongly formatted or maybe the sender went into a different version and the receiver has got no idea about it. What's going on.

C

B

Receivers like oops I have no idea what to do with this message. I'm gonna abandon the lock, and maybe some other receiver can check it out, got it that make sense or the receiver can validate the message and say hey. This message is completely wrong. I or you know some some something went bad on the sender side or some you know, stages hit that.

A

B

Recover from I'm gonna go and dead-letter the message, and that puts it in a sub entity within the queue wherein you can go and analyze all these messages and say: hey now, I know exactly what's happening with my system right and then have a recovery mechanism. Cool sounds good, yeah.

A

Now I know we have some topics.

A

D

A

Some some some features known as like cues and topics right right, like who we talk about a little bit. What are the differences between cues and topics because.

C

In my head, like.

A

Service bus is like a message broker right, and that means that messages it takes. mmm You know, accuse up messages and it passes it out to different people right. So, what's the difference between like this cue concept on the topic concept, right, yeah.

B

So so, semantically speaking, there are two ways to think of messaging right. You have the point-to-point, wherein one sender and one receiver, that.

C

B

A group of senders, but they are similarly you know they're essentially similar in their in their function. Sure you could like I mentioned, you can horizontally scale up your senders and when they're all doing the same function on the same side, you have a whole bunch of receivers that are also doing the same function. But again you can horizontally scale them up as well. Yeah.

D

B

Now you have, you know you can have competing consumer patterns but they're all reading from the same cue, yeah.

D

B

It's exactly point-to-point, you essentially mapping one function to another function, hmm but let's say your messages are, you know, need to reach multiple destinations right. So it's more of a publish/subscribe yeah.

D

B

You know it's a publish/subscribe scan loaded term, we kind of treated as multiplex and a fan-out. Okay I just say you know what I'm gonna have one topic that the sender only knows about, and the sender will only send to a topic. Yeah.

D

B

Then, on the receiving side we can set up subscriptions and the way it works is that you set up subscriptions. You could have you could set up a filter on these subscriptions and say this subscription only cares about these messages. Yeah right with this particular criteria. With this particular criteria, you.

D

B

Say I'm interested in all messages you could say I'm interested in a certain type. You could essentially filter based on any of the message. Header properties. Okay, so let's say you know your sender is this all-powerful being that is doing. All sorts of message sends whether you know in the e-commerce scenario whether it's a new order or you know a bank inquiry or you know, success. You know from the bank a tweak. That's only comes in yeah.

D

B

You know the sender sending everything, but it needs to be rather two different. You know applications and different Department different things to process that message exactly so different things need to process a message. Some some messages need to go to both Yeah.

D

B

You know there are all these different use cases that you can leverage, and you can say you know one as a sender I'm only going to send at that topic. But then I'm gonna have filters on where your subscriptions and then these messages will get replicated over your router to a single one. So what I mean by replication in this case is that if a message only satisfies one filter condition, it goes only in that subscription. Yeah.

D

B

If it satisfies both, it is replicated both got.

D

B

So it's not like the competing consumers on different subscriptions, they will have their own copy and they can leverage their own processing mechanism to write.

A

B

Subscription, okay,.

A

So so, just just for me to clarify so when we're talking about service bus, cues, right right, like it's, someone, someone like a point-to-point right, so I can't have multiple consumers attached to a single queue. You.

B

Can you can yes, but but they will all be competing with each other? What.

A

Are we fighting for yeah the ability to do.

B

And and that's and that's not a bad thing, it's basically it's a different model right when.

C

B

Have receivers doing the exact same thing you can essentially have them, compete against each other to process message they're on the same queue? It's basically like you know, do you know, and you want just one receiver reading and processing it or you do want five I'll.

C

A

To five I got.

D

They're doing the same thing: it's just you.

B

Know it's as if the same receiver is reading the message. Yeah.

A

B

Now you're scanning up as well: okay.

A

Cool all right, so that make sense so then I can have at that point to point scenario.

C

A

Going to one cue right, but then I can have multiple folks I think one.

B

A

More people like working on, though mm-hm and it with topics now now I, have a little bit more intelligence, because routing comes into play right right, I can do filtering, I can do broadcast and.

D

What it sounds like I could actually have this.

A

Thing go across multiple people or sort of subsets of the workers that want to process this work right.

B

That's that's exactly right, and, and so the way it works is that you know the center of a she knows only about the topic. The receiver, on the other hand, knows only about the subscriptions got.

A

B

For all intents and purposes, the subscription behaves like queue, so the receiver I mean there's no different, there's no difference in whether it's talking to a queue or a subscription. Okay into the same unit, locking mechanism lock process complete abandoned dead letter, all that good stuff, okay and and the way it works is, as you can see, any animation. The order will be sent over to the subscription that has that filter condition satisfied and then the court will go over there as well. Okay,.

A

On the in the other one cool yeah, let's move forward I'll, take a look at a sample and see what like this. This code looks like sure.

B

So sending two queues and topics again like I mentioned these, are you know the routing concept of you know? Topics and subscriptions is a service side detail. You know from the application side whether it's a queue or a topic. Your code looks slightly different because there are different opportunities over there. Yeah.

D

B

You know functionality for queues and topics, but the API gestures are comparable. So in the first case we instantiate the queue client. You.

D

B

Either do the queue client, if you're, sending to a queue yeah or you can use the topic line when you send into a topic Kara and from that point forward, the code is identical, you would send, as is you, you know, just create a message. We just put a random great on the message: ID yeah.

D

B

Just send it out there yeah and you know we have a synchronous message. That's exactly what we recommend, because we.

A

Don't want your sender to be blocking your your process right, I got it and.

B

And the idea is that you know you can get a callback on. You know like any asynchronous method. We do have a throughput and latency are two different concepts, so you can have high throughput and since your application will not block latency is something you need. You need not worry about. Yeah.

D

Obviously, but.

B

We still have latency under 100, milliseconds, okay cool, that's.

A

Awesome and so as we're looking at this sample.

C

Here, whenever.

A

We're creating messages right, like the sample right here, just shows like content type of message: ID right but I'm, guessing I could set all a lot of different options like the actual payload for the message. Custom properties, headers right tons of different things right right, because I think that comes into play. When we talk about routing out right, absolutely like we could, we could add these different pieces of metadata.

B

To the message as we send it yeah, so we do have user properties. We have system properties and I try to keep this as simple as possible. Sure sure sure.

C

B

We do have this available as well. The data payloads are binary, so we cannot have a filtering on the data payloads. It's only on the header yeah.

D

B

Is which is pretty standard in the messaging space? And then we have these SDKs that can help you serialize and deserialize, when you, when you put it back off gosh you're, cooking.

A

Awesome so let's move forward and talk a little bit about I think they have the next section we're gonna talk about the tears right, yeah.

B

So so we offer service bus in into tears. We have the standard here and at the premium tier- and you know we initially start with the standard here. It was a multi-tenant pay-as-you-go model with message size up to 256, KB yeah.

D

B

The idea was that most customers needed dedicated resources and that could give you in a predictable throughput latency. You.

D

B

Know bigger message, sizes and all the enterprise features that are required.

D

You know, for you, know, high.

B

Availability, disaster recovery. You know virtual network service endpoints, you know having man service identity, you know all the other good stuff that makes it and price ready. So that's why we kind of made this offering available a little over three years back. I.

D

B

Premium tier- and that gives you you know- exclusive resources you can allocate in terms of message units mm-hmm, so you could provision the service bus namespace in premium yep. You could provide it with one two, four or eight message units. Oh and the rough estimation is one mu- is equal to 1, BM yeah.

D

B

That gives you sufficient sandbox dedicated resources that.

A

B

A

B

You can leverage it and you can also scale up and scale down, depending on whatever.

A

You need happens to be yeah, so it kind of sounds like, depending on what my size of my company is many.

D

A

We're doing right like we could probably start off with standard right and you, you know dev test scenario. So if we're doing small workloads, but you have a medium-sized company and we're not putting out like thousands and millions of messages, hmm but then, when I do get to that that higher scale right no I can have things like you know like the Geo recovery, and you know bigger message, sizes and those types of things for my production workloads. If I go to a premium, that's.

B

Exactly right, so so that's exactly where recommendation is. If you have dev tests and low throughput environments, you standard once you get to that, that's scale, you can start using premium. If you have bigger message: payload requirements, yeah.

D

B

Any kind of enterprise features and in the past we we do not have a way to essentially migrate yeah.

D

B

Know your existing standard namespace to premium, but we made that change so now would standard and your applications are. You know like coated against that connection. String, yeah.

D

B

A simple one that solution to essentially migrate your standard to premium. Okay, awesome, that's great yeah cool. What one one thing I want to add about premium is, since it's dedicated resources, I.

C

B

Upon this earlier, when you can scale up or scale down, depending on your use case, we will hourly on both are so both are tears. So let's say you have a sudden spike in your. You know in your workload, yeah.

D

B

You want to essentially make sure their process quickly. You can, you know, keep an eye out for CPU and memory usage.

D

Metrics, you know, depending.

B

On that, you could essentially scale up to do a muse, yeah.

D

B

Your workload goes back to normal, which, again you can track me using the CPU and memory usage metrics. You can scale back down to one and you only pay the premium for the slight.

A

Damage for that period of time and then just go back now, yeah.

C

A

So that gives you a little bit more control over like how you use the service. That's exactly right! Awesome! This is really cool. So do we have anything else really quickly before we wrap up that we want to talk about about our service book. Sure.

B

So I also talked about what our target scenarios look like. You know when you know we spoke of the use cases, but what scenarios are we targeting as team and and the way we think of it? Is you know you have two cases right? You have the lift, shift and modernize you.

D

B

You have existing on-premise solutions and we want to bring you in in a controlled fashion, to a sure, yeah and, and the goals here are to make your migration as simple as possible and also, at the same time, empower you to pick as modules along the way. So any kind of past offerings that we offer that work better for you use case, and then your on-prem solutions, that's something we want to empower you to do that sure, and how do we do that?

B

We essentially have you know the familiar semantics that you've been using in your in your prior queuing service. No, these are enterprise features and secured by design. We have well-documented SDKs and we're also expanding support to other well established messaging API is like JMS Jamis.

A

Okay, that's awesome, so that means that if I had an on-premises solution that uses something like activemq or you know some other amqp 1.0.

D

A

Right supported server that I could use. You know. I could shift from that to add your service bus. That's maybe.

B

Because we support.

A

The same protocol, you know the only difference is like instead of me, hosting it I just go to hosting and we're inside of the cloud. That's.

B

Exactly right and and it's not just about the protocol- it talks about what API services you do, your user sure our goal is to make sure that when you use, when you move from on-prem to Azure you you do that with limited code, changes and.

D

B

Config only so that's the path we are going towards. Okay and the second target scenario, is you know if you think you have any kind of modern cloud native solutions No now that is something you're building on the cloud for the cloud and I, don't know with the cloud everything.

A

B

But but the way it works is there, you know obviously messaging as a concept is very old, but we want to modernize it and the.

C

B

We do that is we play well with other ads or pass offerings yeah.

D

B

You know Asset logic, apps are function, sure I should amend, grid is homegrown, it's part of the same team. Sure.

C

B

Essentially, you can play well with you know: hey if there's an event, I want to you know decoupled my my receiver, application I want to send it to a queue or I want to trigger off this agile function or logic app and send an email when, when a message is drop and my queue all of those good things can be built from within either itself and that's really simplify your program model as you build these cloud native solutions, yeah.

A

I think integration between different services is a huge benefit when it talks to talks to about moving to the cloud and, like you know, picking you know what what are good to be the components that I'm going to use. That's right. You know it makes my job as a developer easier. You.

C

A

From a business perspective, it just makes things a lot less complicated, totally.

B

Yeah and that's the goal with with these two targets and notice that we.

A

Have cool that's awesome and I'm, looking forward to talking you some more about as your service bus, we're gonna have to do some more videos and continue this conversation absolutely, but thank you so much for coming on. I really appreciate it and I.

B

A

For watching this has been another episode of the on.net show, and we've learned just a little bit about as your service bus.

A