Interesting facts about Azure BizTalk Hybrid Connections!


Currently I’m contributing to a project which requires to connect Azure and сlient data-centers in order to load different kind of client data into Azure. I’ve investigated different options for our solution including Express Route, VPN Gateway and Hybrid Connections. At the end the choice was made in the direction of Hybrid Connections at current phase of the project. Let me briefly explain why. 

Intro to Azure BizTalk Hybrid Connections

Hybrid Connections is a feature of Azure BizTalk Service which allows you to establish secure HTTPs connections between Azure and client data-centers without providing access to client resources from web (requires outbound TCP or HTTP connectivity from client private network). Under the hood this feature uses Azure Service Bus Relay and requires Connection Manager to be installed to a client data-center which acts as a listener for incoming requests from Azure and as a proxy for client resources.

Withing Hybrid Connections you can connect any on-prem resources linked to static TCP port to the cloud without any special actions. As per official documentation, you can not connect on-prem LDAP or resources with dynamic TCP port. One interesting fact there that in scope of my research I was able to connect on-prem LDAP with static TCP port to Azure successfully. So it’s possible!

Also it’s very easy to connect to on-prem client resources when you’re using Azure App Service. You just need to add your hybrid connections to Azure App Service using Azure Portal or PS. And that’s it! You don’t need to write and maintain custom code for managing connections and data transferring. App Service already integrated with Hybrid Connections under the hood. It monitors all out-coming network calls and proxy them to Azure Service Bus Relay if hostname and port matches to hostname and port of HC. It helps our life much easier! You can learn more about HC on official documentation.

Throughput of Hybrid Connections

As you can see Hybrid Connections allows you to connect client on-prem resources to Azure without overheads which required for dedicated VPN (install & configure VPN server on client side) or Express Route (contracts with 3rd party providers of dedicated network channels). And this is very beneficial because you can safe lots of money and maintenance efforts as well as simplify client on-boarding process and time needed for that.

But at the same time that’s clear that HCs technology doesn’t provide such throughput capabilities as dedicated VPN or ExpressRoute can. That was our major concern during technology comparison. To address that we’ve performed quick PoC in order to measure throughput and to get some numbers to consider.

Before going to the results that we’ve got from PoC I’d like to quickly walk you thought the pricing model for HCs. Currently you have to provision Azure Biz Talk service which will act as a container for HCs. It’s coming with multiple pricing tiers: Free, Developer, Basic, Standard, Premium. Each of pricing tiers of BizTalk provides different capabilities including number of HCs which can be provisioned. Also as most of the folks I assumed that higher pricing tier provides higher throughput for HCs as well as bigger number of HCs in scope of one BizTalk service will affect throughput. But that’s not true! Let’s take a look into PoC results.

In scope of PoC I’ve connected my local machine from Boston to East US Azure DC by using HCs from BizTalk Services with different pricing tier (Basic, Standard, Premium).

EAST US (~670 miles from Boston)
Body Size Speed per BizTalk Service Pricing Tier
Basic Tier Standard Premium
Max Min Max Min Max Min
ping (167 byte) 00:00:00.71 00:00:00.14 00:00:00.49 00:00:00.14 00:00:00.88 00:00:00.14
1 MB 00:00:02.00 00:00:00.88 00:00:01.48 00:00:00.86 00:00:01.48 00:00:00.51
10 MB 00:00:04.94 00:00:03.51 00:00:04.62 00:00:02.80 00:00:05.06 00:00:02.78
100 MB 00:00:29.78 00:00:26.13 00:00:25.39 00:00:22.79 00:00:28.84 00:00:23.85
500MB 00:02:16.33 00:02:06.49 00:02:05.60 00:01:56.77 00:02:09.84 00:01:56.91

As you can see from table above there is no significant difference between HCs from Premium and Basic pricing tiers. That’s mean that for multi-tenant scenario you don’t need to create BizTalk service per client. Instead of that you have to create HCs per client within shared BizTalk service.

For our particular purposes PoC results has been satisfactory and allowed to get acceptable performance as well as save money and time for client on-boarding which is critical for business.

Azure Relay Hybrid Connections as a replacement of Azure BizTalk Hybrid Connections?

I hope you noticed few uncomfortable moments with Hybrid Connections… In order to use them you have to provision Azure Biz Talk service and pay for it.. I guess that’s due to historical evolution of this service. Another moment is that Hybrid Connection manager which should be installed to client data-center utilizes WCF which brings difficulties for cross-platform scenarios. Anyway changes are coming!

Microsoft just announced general availability of Azure Relay Hybrid Connections. This is new offering which doesn’t require Azure BizTalk service and provides lighter and flexible pricing model. At the same time new offering breaks dependency on WCF as well as introduces communication between Azure and client DC in secure fashion using WebSockets! But I assume that throughput should be the same as for BizTalk HC because under the hood both of the technologies are using Azure Service Bus Relay. Anyhow that’s a good thing to verify and create another PoC :).

Despite the advantages of Azure Relay HC there are still some drawbacks at the moment and because of them I stick to BizTalk HCs for particular project for now:

  1. No built-in integration with Azure App Service. You have to write custom code to manage hybrid connections and transfer data (at the same time it provides some degree of flexibility).
  2. There is no manager or listener which can be installed to client data-centers and connect to Azure Relay Hybrid Connections. You have to write your custom code to connect and proxying requests to on-rem resources.

Anyhow I believe that these kind of drawbacks are temporary and will be solved in near future by Microsoft and then I’ll safely switch to Azure Relay! Thank you for reading!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s