In this scenario we would be using a Relay. This is yet another way of connecting your on-premises infrastructure to Azure, but not recommended at all in terms of latency. We’ll explain it, don’t worry. We would also be using an Hybrid Connection to establish a “link” between my local machine and Function Apps.
First step is to configure an Hybrid Connection in Function Apps network configuration. Then, you can run Hybrid Connection Manager (assuming you’ve downloaded it from Azure), to manage your connection.
After saving which connection you want to use, you can always confirm connection status in this window:
But wait, I see Service Bus referenced in that print screen! What’s that?
Service Bus is a technology of asynchronously sending and receiving messages from multiple publishers to multiple subscribers. This is, as you’ve probably guessed, a publish/subscribe mechanism.
This is an example of a publish/subscribe architecture. The image should be self-explanatory. A sender sends a message, and all subscribers have filters to only process the messages that they subscribe to.
Why didn’t you test this method?
Well, before you call me anything, you got to understand why.
Architecture!
This concept relies on checking the bus for new messages from time to time, with a 10 second interval for instance. Each 10 second, your program/service, or whatever you want to call it, will check the bus for new messages and retrieves them. This generates a “waiting game”, that’s why it’s called an asynchronous process. It’s not designed to be fast, but to be reliable and to connect multiple services into one giant message box.
Example:
A highway. A highway in USA connects multiple states together, and you can choose where to leave it. You can choose a city in a certain state, or a totally different city in another state, it just depends where you’re going to. This is the same. The service bus it’s like that highway. A publisher publishes a car. Each message (car) has a topic (destination), and every subscriber (city/state) retrieves a message (car) depending on their topic (destination).
This is the main reason that latency doesn’t apply here. It’s a very robust and clean way of integrating services with applications, but latency isn’t a concern here. It’s just not made to be fast. It’s made to be simple.
Conclusions and summary next post!
