Hybrid Connections versus Relay

I found an excellent post on the question whether to use Hybrid Connections or a Relay. Both techniques actually use the relay concept under the covers. That essentially means both techniques are firewall friendly. No inbound ports are required to expose on premise services, just outbound connections. In fact, there aren’t that many features with Hybrid Connections which would give you a big benefit versus what you might get with Service Bus Relay. So the important question remains: What’s the difference?

First of all a software agent gets installed on premise if you are using Hybrid Connections. With Service Bus Relays nothing gets installed on premise and you can either modify and expose the service itself or build a facade WCF Service (or the WCF Routing Service) and use a so-called relay binding. Note that relays can only be called from WCF clients. Another angle to look at it. Hybrid Connections requires the BizTalk Services feature. This gives you some more integration features, but it also comes with a higher cost. Service Bus Relay is a smaller feature within Azure and is currently lower cost.

Scenarios when it’s best to use Hybrid Connections:
•The client is hosted inside of Azure
•You want to integrate directly with a resource, which is not hosted in WCF. Eg: you want to connect directly to a database
•The client wanting to connect to the resource is not able to talk WCF and perhaps isn’t even a Microsoft technology
•You want to create a point to point tightly coupled connection from a cloud resource to an on premise resource
•You are already using Hybrid Connections in your architecture

Scenarios when it’s best to use relays:
•The client is hosted outside of Azure
•The client is hosted on a resource in Azure which is not supported by Hybrid Connections (see documentation for more info)
•You want to connect your WCF service directly to the cloud rather than having an on-premise man in the middle style agent installed
•You are already using Service Bus Relay in your architecture

Other differences:

• From a security perspective there are some notable differences. If you use hybrid connections you use SAS which is abstracted from the consuming technology. Using Service Bus Relay you need to use ACS. This means your client needs to be able to get an ACS token via WCF bindings or REST.
• With Hybrid Connections you’re talking to a service at a port level.  This means that you can connect to any service exposed at that address and on that port.  If we are bridging through to an IIS server we would be able to get to all WCF services in this WCF component on that port (for instance port 80).  Obviously this could be a problem, although there may be some application specific security. With Service Bus Relay things are slightly different. You are able to configure the service to only use specific WCF services to open an endpoint in the cloud.

Further information can be found at the following link: blogpost

Hybrid connections

This post highlights some findings from the presentation on hybrid connections held by Michael Stephenson at Integrate 2014. The modern enterprise needs a means to connect the on premise and the cloud world. There are many technology options, so we need to use the right tool for the right job. It’s also important to incorporate change. We must be able to change tools if required (agility).

Before looking at the various connectivity options, it’s good to start off with a base type scenario of integration. We could connect the cloud environment and the on-premise enviroment by setting up an on premise SFTP server. SFTP is supported by BizTalk out-of-the-box, and it’s perfectly usable in base scenarios. But, if we want or need to go along the Azure route, the connectivity options can be grouped in three categories: Azure Networking, Azure Service Bus and BizTalk Services. See the overview below:

Azure Networking basically is about setting up a VPN connection between your datacenter and the Microsoft datacenter in the cloud, that is: Site to Site VPN. Just as a little sidestep. Point to Site VPN is needed when you have a global development team and you want to connect your development machine to the shared cloud development environment. There may be network security issues that prevent you from doing that, so then you need what we call Point to Site VPN.

With Site to Site VPN, you are not talking about connecting a single machine to the cloud, but an entire network. In order to do that you will definitely need support from the infrastructure team and you will be confronted with all the complexity and through-put time you will have when setting up a regular VPN connection. The key benefit is of course: network level access between on premise and cloud resources (one virtual network). The constraint is that you will have to setup a virtual network in Azure, not just individual unbound cloud resources.

Service Bus connections, especially service bus relays, are probably the most simple and cost effective way to connect to the cloud. A common scenario is where you use the service facade or service proxy pattern to build webservices (or use the WCF Routing Service) that encapsulate the on premise applications. This reduces the complexity of connecting to on premise applications. The constraints are that you can only use WCF relay bindings and that you have limited opportunities for management and monitoring. The second constraints is not a real constraint because you can use relay services in combination with Azure API Management.

Of course you can also use Azure Service Bus Messaging (queues and topics). Advantages are again that it’s simple and low cost. Next to that you can support high volume and different communication patterns. Support is limited to Advanced Message Queuing Protocol (AMQP), REST and SB-Messaging.

The last hybrid connection options are related to Azure BizTalk Services or bridge services. With the advent of the micro services architecture, the future prospects of this technology are unclear. What you can do, is set up a hybrid connection or a BizTalk Adapter Service. A BizTalk Adapter Service is basically a BizTalk adapter style connection to common LOB systems like SQL Server, SAP or Oracle. It’s easy because it is a similar experience to using the LOB Adapter Pack from BizTalk. Usage is not limited to BizTalk Services, but you can also use it from other applications like a WCF Service. Downside is that you need a BizTalk Services subscription (only interesting when you have a lot of usage opportunities, otherwise a bit overdone because there are good alternatives to bridges).

With Hybrid Connections you create a port-level connection to an on premise resource. It is similar to a service bus relay, but with a wider scope of usage. Again you will need a BizTalk Services subscription. Pricing is a key consideration if you aren’t using other BizTalk Services features.

Further Reading: Connecting to on-premise Resources

Points for further analysis:
– WCF Routing Service
– AMQP
– Servicebus Event Hub
– AppFx.ServiceBus framework. Light-weight messaging framework for Azure Service Bus. Based on .Net and available via Codeplex. Scenario: collect messages from the Azure Service Bus and send them to a WCF service. Can be an alternative for BizTalk when there is simple message handling, no complex transformations or orchestration, etc.
– SendGrid (Azure add-on). Sending email notifications without connection to the on premise Exchange Server. Email service which we can access over SMTP (standard BizTalk sendport).
– Book: Applied Architecture Patterns on the Microsoft Platform