Betatalks the podcast

32. Working with Service Bus, Event Hubs, Event Grid, CloudEvents and Relay Service - with Clemens Vasters

In this episode, we talk to Clemens Vasters. He works at Microsoft on the Azure product engineering team. Specifically, he is a Principal Architect for Service Bus, Event Hubs, Event Grid and Relay. We dive into these services, what they can do and how they differ. Clemens explains why and when to use events or messages, and what types of scenarios they fit into; from discrete events and event series to jobs, commands and processing. And we discuss working with CloudEvents in Event Grid. Furthermore, we talk about the origins of the term Red Dog, how Azure emerged, easter eggs, and the Relay Service, which even predates Azure, and the evolution of the service.

About this episode, and Clemens in particular: you can find @clemensv on Twitter or check out some of his blogs.

About Betatalks: have a look at our videos and join us on our Betatalks Discord channel


Terug naar het overzicht van alle podcasts

Transcript

Introduction

Rick: Hey there. Welcome to Betatalks, the podcast in which we talk to friends from the development community.

Rick: I'm Rick.

Oscar: And I am Oscar.

Rick: Oscar, have you been what have you been up to?

Oscar: I've been good. Multiple things, multiple projects, was playing around and we actually made a video on this like I played around with I don't know. You know it? I know it. With Relay service in Azure

Rick: Because first we were looking at, oh, we have to punch holes in the firewall and make sure that the Internet connected service can talk to our on premises service.

Oscar: Yeah. And then you need to talk to some network guys let's avoid that.

Rick: Who are not all too happy.

Oscar: No. And it was just a temporary setup. So we kind of made a good set up there. And I really see some use in different scenarios there because we had a closed onprem and we actually had some devices there behind the firewall and now we open it up and we can continue as if it was already placed in a new situation.

Rick: Yeah.

Rick: So especially in these types of migration scenarios or hybrid scenarios because, well, there is some hardware locally that you actually need to address, but the rest of your application is running in the cloud. Then Azure Relay is a pretty neat option.

Oscar: Yeah, it was good. And I remember that we used it in the past, of course, but I completely forgot about the service. And that's the thing now with Azure, right. There's so many services that you start forgetting about it. They're even there until you really have a scenario again.

Rick: Yeah, true

Oscar: So yeah, that was good.

Rick: Cool. So, Oscar, who's our friend of the day

Oscar: Our friend of the day is Clements Fasters.

Rick: Clemens Vaster works at Microsoft on the Microsoft Azure product engineering team. He is a principal architect for Service Bus, Event Hubs, Event Grid, and Relay, laying the groundwork for future development work and driving technical strategy. He is also a cochair of the Oasis AMQP Technical Committee, member of the Mqttc, and next to that, he represents Microsoft in the CNCF Cloud Events Working Group. His personal passion is researching military aviation history, especially of the Cold War. And he has an extensive public photo archive from some of the most significant aviation museums in the world.

Messaging & Events

Oscar: Welcome, Clements.

Rick: Welcome

Clemens: Hello. I'm very pleased that you have me. And it's an honor to be on this podcast.

Oscar: Well, it's an honor to have you here. You're kind of a legend in messaging, right?

Clemens: Well, I'm just doing my job.

Rick: Well, apparently you're doing a good one.

Oscar: Yeah. I think you have your signature over a lot of services I've been using in the past and also, I think, for the Relay service we were just talking about. Right.

Clemens: Yeah. The Relay is actually by far the oldest service in the Azure service portfolio because it existed before Azure was even named Azure or there was even a coherent cloud strategy at Microsoft. The first public preview, if you will, was under the name Livelapse in May 2006.

Oscar: Wow.

Clemens: Yes. And the principle of the relay hasn't really changed since then. I think we've, meanwhile, killed all the code from back in the day, but all the service bus helds back to that original service. And relay by now has changed protocols, the primary protocol, so that's now purely WebSocket based, but in principle it's still the same thing and helps with the same problems.

Oscar: Yeah, I remember relay was a topic when WCF was really big and one of the cool demos was always having WCF talking to WCF on the same environment and it actually detected you were both behind the same firewall and it just upgraded to connection. It was really magical demo always to do.

Clemens: So that part actually has an even cooler aspect to it and that's actually still in the if you use the Windows Azure clients. So we have three or four .Net clients. Over time they've changed. And the oldest one that is still out there, because that's the one that still supports WCF and has the relay client in it, there is on the net TCP relay binding, there's a switch called hybrid. And when you turn that on, so this is something you could use today, if you turn that on, we're using a special mechanism where you can have two endpoints that are sitting behind firewalls. You can have a listener that sits behind an Nat and a firewall, and the client also sits behind the Nat and a firewall. And we're making a prediction about the behavior of the net device as the connection is being established. So the connection is being established through the relay. And then they're effectively talking about each other through the relay and making a guess which ports on the Nats will open next. Because the way how Nats allocate their outbound and inbound ports is basically they go in the 32,000 range and go one by one by one by one, so the next connection gets to the next port.

Clemens: And so we're making a guess about that. And then we're effectively snapping a socket through those firewalls and through those Nats, making effectively a two outbound connections which meet each other in the middle. And that makes us possible to snap a socket that is direct between those two parties, which both sits behind Nats and firewalls through a guessing game in negotiation that the relay helps with. It's pretty magic. You end up with a direct socket.

Rick: And then I think this is the cool thing, if we start this type of discussion and immediately we go into this level of tech detail, this is awesome. That's cool.

Clemens: Yeah, so it's just because he started on it and then I thought I'd just give you a little technical nugget here to start the discussion. It's some amazing tech. And the relay has helped many customers with what you just opened the story with. And that is I have some service that sits behind a firewall and I need to go and reach that from the cloud, or I need to reach that from clients, and I need to do a quick tactical thing to go and just get to it. And we have many customers who have started with that to say, oh, I just need to have a little POC and a trick to just avoid talking to my networking people and create these routes and do all that work and VPNs and whatever. And these tactical POCs tend to be super sticky and end up being the thing that customers just use.

Oscar: Yeah. And in the end, the proof of concept. Also, what we did, like, this works and it kind of works already. It's so low code and it's done, and it's actually more secure than anything you would set up by punching holes in the firewall. I can imagine it's sticky.

Rick: All of these temporary solutions that are in production now permanently, probably.

Clemens: Yes

Rick: As they tend to be. Let's take a few steps back, Clements, because you work on both Service Bus, but also Event Hubs and also Event Grid. Now, I know that there are different types of events, and then events are for more specific needs than messages are. Could you, on a somewhat higher level try and explain why you would use either events or messages or in which types of scenarios that would fit?

Clemens: Yeah, as you correctly observed, we have three services, and arguably we even have eight. But let's stick to the three ones that you just mentioned. The first distinction I would draw is between jobs and commands on one hand, and then events on the other side. There are different characteristics to those messages, even though they look the same. So there are semantic differences in an event versus a job or command that cause different architectural decisions. An event is a statement of fact about something that just happened. And that statement of fact is something that you can then go and react to if it's what I call a discrete event, which means it is a lab.

 


Transcript

[00:00:08.170] - Oscar
Hey there. Welcome to Betatalks, the podcast in which we talk to friends from the development community.

[00:00:13.080] - Rick
I'm Rick.

[00:00:13.810] - Oscar
And I am Oscar.

[00:00:15.110] - Rick
Oscar, have you been what have you been up to?

[00:00:17.980] - Oscar
I've been good. Multiple things, multiple projects, was playing around and we actually made a video on this like I played around with I don't know. You know it? I know it. With Relay service in Azure

[00:00:35.290] - Rick
Because first we were looking at, oh, we have to punch holes in the firewall and make sure that the Internet connected service can talk to our on premises service.

[00:00:43.120] - Oscar
Yeah. And then you need to talk to some network guys let's avoid that.

[00:00:47.530] - Rick
Who are not all too happy.

[00:00:48.950] - Oscar
No. And it was just a temporary setup. So we kind of made a good set up there. And I really see some use in different scenarios there because we had a closed onprem and we actually had some devices there behind the firewall and now we open it up and we can continue as if it was already placed in a new situation.

[00:01:10.670] - Rick
Yeah.

[00:01:10.810] - Rick
So especially in these types of migration scenarios or hybrid scenarios because, well, there is some hardware locally that you actually need to address, but the rest of your application is running in the cloud. Then Azure Relay is a pretty neat option.

[00:01:25.920] - Oscar
Yeah, it was good. And I remember that we used it in the past, of course, but I completely forgot about the service. And that's the thing now with Azure, right. There's so many services that you start forgetting about it. They're even there until you really have a scenario again.

[00:01:40.650] - Rick
Yeah, true

[00:01:42.000] - Oscar
So yeah, that was good.

[00:01:43.560] - Rick
Cool. So, Oscar, who's our friend of the day?

[00:01:46.980] - Oscar
Our friend of the day is Clements Fasters.

[00:01:52.150] - Rick
Clemens Vaster works at Microsoft on the Microsoft Azure product engineering team. He is a principal architect for Service Bus, Event Hubs, Event Grid, and Relay, laying the groundwork for future development work and driving technical strategy. He is also a cochair of the Oasis AMQP Technical Committee, member of the Mqttc, and next to that, he represents Microsoft in the CNCF Cloud Events Working Group. His personal passion is researching military aviation history, especially of the Cold War. And he has an extensive public photo archive from some of the most significant aviation museums in the world.

[00:02:30.610] - Oscar
Welcome, Clements.

[00:02:31.310] - Rick
Welcome.

[00:02:32.270] - Clemens
Hello. I'm very pleased that you have me. And it's an honor to be on this podcast.

[00:02:39.190] - Oscar
Well, it's an honor to have you here. You're kind of a legend in messaging, right?

[00:02:44.450] - Clemens
Well, I'm just doing my job.

[00:02:47.940] - Rick
Well, apparently you're doing a good one.

[00:02:50.730] - Oscar
Yeah. I think you have your signature over a lot of services I've been using in the past and also, I think, for the Relay service we were just talking about. Right.

[00:03:06.400] - Clemens
Yeah. The Relay is actually by far the oldest service in the Azure service portfolio because it existed before Azure was even named Azure or there was even a coherent cloud strategy at Microsoft. The first public preview, if you will, was under the name Livelapse in May 2006.

[00:03:34.680] - Oscar
Wow.

[00:03:37.040] - Clemens
Yes. And the principle of the relay hasn't really changed since then. I think we've, meanwhile, killed all the code from back in the day, but all the service bus helds back to that original service. And relay by now has changed protocols, the primary protocol, so that's now purely WebSocket based, but in principle it's still the same thing and helps with the same problems.

[00:04:13.310] - Oscar
Yeah, I remember relay was a topic when WCF was really big and one of the cool demos was always having WCF talking to WCF on the same environment and it actually detected you were both behind the same firewall and it just upgraded to connection. It was really magical demo always to do.

[00:04:42.480] - Clemens
So that part actually has an even cooler aspect to it and that's actually still in the if you use the Windows Azure clients. So we have three or four .Net clients. Over time they've changed. And the oldest one that is still out there, because that's the one that still supports WCF and has the relay client in it, there is on the net TCP relay binding, there's a switch called hybrid. And when you turn that on, so this is something you could use today, if you turn that on, we're using a special mechanism where you can have two endpoints that are sitting behind firewalls. You can have a listener that sits behind an Nat and a firewall, and the client also sits behind the Nat and a firewall. And we're making a prediction about the behavior of the net device as the connection is being established. So the connection is being established through the relay. And then they're effectively talking about each other through the relay and making a guess which ports on the Nats will open next. Because the way how Nats allocate their outbound and inbound ports is basically they go in the 32,000 range and go one by one by one by one, so the next connection gets to the next port.

[00:06:10.450] - Clemens
And so we're making a guess about that. And then we're effectively snapping a socket through those firewalls and through those Nats, making effectively a two outbound connections which meet each other in the middle. And that makes us possible to snap a socket that is direct between those two parties, which both sits behind Nats and firewalls through a guessing game in negotiation that the relay helps with. It's pretty magic. You end up with a direct socket.

[00:06:44.060] - Rick
And then I think this is the cool thing, if we start this type of discussion and immediately we go into this level of tech detail, this is awesome. That's cool.

[00:06:56.190] - Clemens
Yeah, so it's just because he started on it and then I thought I'd just give you a little technical nugget here to start the discussion. It's some amazing tech. And the relay has helped many customers with what you just opened the story with. And that is I have some service that sits behind a firewall and I need to go and reach that from the cloud, or I need to reach that from clients, and I need to do a quick tactical thing to go and just get to it. And we have many customers who have started with that to say, oh, I just need to have a little POC and a trick to just avoid talking to my networking people and create these routes and do all that work and VPNs and whatever. And these tactical POCs tend to be super sticky and end up being the thing that customers just use.

[00:07:55.040] - Oscar
Yeah. And in the end, the proof of concept. Also, what we did, like, this works and it kind of works already. It's so low code and it's done, and it's actually more secure than anything you would set up by punching holes in the firewall. I can imagine it's sticky.

[00:08:16.980] - Rick
All of these temporary solutions that are in production now permanently, probably.

[00:08:21.610] - Clemens
Yes

[00:08:22.860] - Rick
As they tend to be. Let's take a few steps back, Clements, because you work on both Service Bus, but also Event Hubs and also Event Grid. Now, I know that there are different types of events, and then events are for more specific needs than messages are. Could you, on a somewhat higher level try and explain why you would use either events or messages or in which types of scenarios that would fit?

[00:08:54.090] - Clemens
Yeah, as you correctly observed, we have three services, and arguably we even have eight. But let's stick to the three ones that you just mentioned. The first distinction I would draw is between jobs and commands on one hand, and then events on the other side. There are different characteristics to those messages, even though they look the same. So there are semantic differences in an event versus a job or command that cause different architectural decisions. An event is a statement of fact about something that just happened. And that statement of fact is something that you can then go and react to if it's what I call a discrete event, which means it is a lab.

 


Transcript

Introduction

Rick: Hey there. Welcome to Betatalks, the podcast in which we talk to friends from the development community.

Rick: I'm Rick.

Oscar: And I am Oscar.

Rick: Oscar, have you been what have you been up to?

Oscar: I've been good. Multiple things, multiple projects, was playing around and we actually made a video on this like I played around with I don't know. You know it? I know it. With Relay service in Azure

Rick: Because first we were looking at, oh, we have to punch holes in the firewall and make sure that the Internet connected service can talk to our on premises service.

Oscar: Yeah. And then you need to talk to some network guys let's avoid that.

Rick: Who are not all too happy.

Oscar: No. And it was just a temporary setup. So we kind of made a good set up there. And I really see some use in different scenarios there because we had a closed onprem and we actually had some devices there behind the firewall and now we open it up and we can continue as if it was already placed in a new situation.

Rick: Yeah.

Rick: So especially in these types of migration scenarios or hybrid scenarios because, well, there is some hardware locally that you actually need to address, but the rest of your application is running in the cloud. Then Azure Relay is a pretty neat option.

Oscar: Yeah, it was good. And I remember that we used it in the past, of course, but I completely forgot about the service. And that's the thing now with Azure, right. There's so many services that you start forgetting about it. They're even there until you really have a scenario again.

Rick: Yeah, true

Oscar: So yeah, that was good.

Rick: Cool. So, Oscar, who's our friend of the day

Oscar: Our friend of the day is Clements Fasters.

Rick: Clemens Vaster works at Microsoft on the Microsoft Azure product engineering team. He is a principal architect for Service Bus, Event Hubs, Event Grid, and Relay, laying the groundwork for future development work and driving technical strategy. He is also a cochair of the Oasis AMQP Technical Committee, member of the Mqttc, and next to that, he represents Microsoft in the CNCF Cloud Events Working Group. His personal passion is researching military aviation history, especially of the Cold War. And he has an extensive public photo archive from some of the most significant aviation museums in the world.

Messaging & Events

Oscar: Welcome, Clements.

Rick: Welcome

Clemens: Hello. I'm very pleased that you have me. And it's an honor to be on this podcast.

Oscar: Well, it's an honor to have you here. You're kind of a legend in messaging, right?

Clemens: Well, I'm just doing my job.

Rick: Well, apparently you're doing a good one.

Oscar: Yeah. I think you have your signature over a lot of services I've been using in the past and also, I think, for the Relay service we were just talking about. Right.

Clemens: Yeah. The Relay is actually by far the oldest service in the Azure service portfolio because it existed before Azure was even named Azure or there was even a coherent cloud strategy at Microsoft. The first public preview, if you will, was under the name Livelapse in May 2006.

Oscar: Wow.

Clemens: Yes. And the principle of the relay hasn't really changed since then. I think we've, meanwhile, killed all the code from back in the day, but all the service bus helds back to that original service. And relay by now has changed protocols, the primary protocol, so that's now purely WebSocket based, but in principle it's still the same thing and helps with the same problems.

Oscar: Yeah, I remember relay was a topic when WCF was really big and one of the cool demos was always having WCF talking to WCF on the same environment and it actually detected you were both behind the same firewall and it just upgraded to connection. It was really magical demo always to do.

Clemens: So that part actually has an even cooler aspect to it and that's actually still in the if you use the Windows Azure clients. So we have three or four .Net clients. Over time they've changed. And the oldest one that is still out there, because that's the one that still supports WCF and has the relay client in it, there is on the net TCP relay binding, there's a switch called hybrid. And when you turn that on, so this is something you could use today, if you turn that on, we're using a special mechanism where you can have two endpoints that are sitting behind firewalls. You can have a listener that sits behind an Nat and a firewall, and the client also sits behind the Nat and a firewall. And we're making a prediction about the behavior of the net device as the connection is being established. So the connection is being established through the relay. And then they're effectively talking about each other through the relay and making a guess which ports on the Nats will open next. Because the way how Nats allocate their outbound and inbound ports is basically they go in the 32,000 range and go one by one by one by one, so the next connection gets to the next port.

Clemens: And so we're making a guess about that. And then we're effectively snapping a socket through those firewalls and through those Nats, making effectively a two outbound connections which meet each other in the middle. And that makes us possible to snap a socket that is direct between those two parties, which both sits behind Nats and firewalls through a guessing game in negotiation that the relay helps with. It's pretty magic. You end up with a direct socket.

Rick: And then I think this is the cool thing, if we start this type of discussion and immediately we go into this level of tech detail, this is awesome. That's cool.

Clemens: Yeah, so it's just because he started on it and then I thought I'd just give you a little technical nugget here to start the discussion. It's some amazing tech. And the relay has helped many customers with what you just opened the story with. And that is I have some service that sits behind a firewall and I need to go and reach that from the cloud, or I need to reach that from clients, and I need to do a quick tactical thing to go and just get to it. And we have many customers who have started with that to say, oh, I just need to have a little POC and a trick to just avoid talking to my networking people and create these routes and do all that work and VPNs and whatever. And these tactical POCs tend to be super sticky and end up being the thing that customers just use.

Oscar: Yeah. And in the end, the proof of concept. Also, what we did, like, this works and it kind of works already. It's so low code and it's done, and it's actually more secure than anything you would set up by punching holes in the firewall. I can imagine it's sticky.

Rick: All of these temporary solutions that are in production now permanently, probably.

Clemens: Yes

Rick: As they tend to be. Let's take a few steps back, Clements, because you work on both Service Bus, but also Event Hubs and also Event Grid. Now, I know that there are different types of events, and then events are for more specific needs than messages are. Could you, on a somewhat higher level try and explain why you would use either events or messages or in which types of scenarios that would fit?

Clemens: Yeah, as you correctly observed, we have three services, and arguably we even have eight. But let's stick to the three ones that you just mentioned. The first distinction I would draw is between jobs and commands on one hand, and then events on the other side. There are different characteristics to those messages, even though they look the same. So there are semantic differences in an event versus a job or command that cause different architectural decisions. An event is a statement of fact about something that just happened. And that statement of fact is something that you can then go and react to if it's what I call a discrete event, which means it is a lab.