With the recent announcement of the release of the BizTalk Hybrid Connections feature one of the first things that many people think is that Hybrid Connections sounds very similar to Azure Service Bus Relay.  While they conceptually sound very similar there are some important differences too.  The obvious question then becomes “why do I need service bus relay when I have hybrid connections”.

Before we get into that question lets take a quick high level look at each technology.

What is Service Bus Relay

Azure Service Bus Relay is a cloud based service which allows you to host an endpoint in the cloud, Azure will use a port forwarding technology to forward messages received from a client to the listening service implementation which is usually hosted on premise.   Service Bus Relay is intended to allow you to bridge from any application hosted in the cloud of on another data center to bridge through to your on-premise services.  You simply use the ACS to provide a client access.

Let’s take a look at Service Bus Relay.

What is Hybrid Connections

Hybrid Connections is a feature in Azure BizTalk Services which allows you to connect Azure Websites and Azure Mobile Services to on-premise resources “as if they are on the same private network”.  To do this you create a hybrid connection and then pair it with your cloud resource.  On premise you would install a software agent which will open up a connection to the cloud and you can configure the hybrid connection to be able to then connect to an on premise resource such as a database.  Your application in the cloud would then be able to connect to the database as if it’s in the same data centre except that the connection string will be modified so that the connection is routed via the BizTalk Hybrid Connection.

Let’s take a look at Hybrid Connections.

What is similar?

Below are some of my thoughts on the similarities on these two products:

• Both products support firewall friendly approach to bridge from cloud to on premise
• Both products open outbound connections from on premise to receive messages.  No inbound ports are required to be exposed from your data centre
• Both products are quite easy to use
• Both products have relatively straight forward infrastructure requirements

What is different?

Below are some of the differences between Service Bus Relay and Hybrid Connections:

• Service Bus Relay only supports a WCF based listening service which uses the WCF relay bindings where as Hybrid Connections uses its on premise listening agent allowing it to connect to a target via any port which can include a WCF or REST service bus also many other applications such as a database
• Service Bus Relay supports ACS security where as Hybrid Connections support SAS for the cloud hosted endpoint.  (Note according to MSDN service bus relay is expected to support SAS sometime in the “near future”)
• The Service Bus Relay endpoint only exists when the listening service comes online where as the hybrid connections endpoint is created in the cloud as a configured service before the agent is listening
• Hybrid Connections provides an agent which can be installed on an on-premise server which can then connect to on premise assets.  Service Bus Relay does not provide any software to install and you need to configure your own listening component or configure a WCF Service to use a Relay binding.
• Service Bus Relay can only support clients which can talk web services and are able to retrieve an access token from ACS, Hybrid Connections can support interop with non .net technologies
• Hybrid Connections can only be consumed by a resource hosted in the cloud such as an Azure Website where as Service Bus Relay can be consumed from a resource hosted outside of Azure such as from a partners data centre
• Hybrid Connections requires the BizTalk Services feature in Azure which also gives you some more integration features but also includes a higher cost.  Service Bus Relay is a smaller feature within Azure and is currently lower cost

Thoughts so far

At this point my thoughts about the new hybrid connections product is that although there is a lot that’s similar between the two products and they do have some overlaps there are also some significant differences between the products two.  Hybrid Connections works at a lower level in the stack working with ports and connectivity and not really caring about the data where as Service Bus Relay is at a higher level, working in the WCF stack meaning there is a greater awareness around how the protocol needs to work which provides some limitations and some benefits.

I think there are likely to be some use cases where the products do not compete with each other because of the different features they offer, but there will also be scenarios where both products could be used and then it becomes a case of which is the right one for your situation.  You need to think about simplicity, what your developers are used to, cost, support aspects and lots of other things.

I expect that the net result the introduction of Hybrid Connections would be that the number of scenarios Service Bus Relay is used in would reduce because sometimes Hybrid Connections might be a more appropriate option and perhaps the way we tend to use Relay may change a little.

Scenarios where I would I use Hybrid Connections

I think that the following list of items would be scenarios where Hybrid Connections are likely to be a better choice:

• 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
• I am already using Hybrid Connections in my architecture and the integration pattern matches the patterns I already use it for

Scenarios where I would I use Service Bus Relay

I think the following list of items would be things would be scenarios of requirements, which would indicate service bus relay would be the only choice you could use:

• 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
• I am already using Service Bus Relay in my architecture and the integration pattern matches the patterns I already use it for

Scenarios where I could use either

For both products there are some clear requirements or constraints where one is more favorable than the other or one product simply wouldn’t be an option, but it will be very common that you could choose either product.  This scenario is going to involve invoking WCF Services on premise from a resource in the cloud.

With Service Bus Relay you would connect your service to the relay using the WCF relay bindings and then call it using a WCF client or alternatively with Hybrid Connections you would install the on premise agent software and pair your hybrid connection with the cloud resource so you could then call the WCF service as if your local to it.

I think at this point the architecture decision comes down to your strategic use of these products.  If your already a service bus relay user and are happy with it then your probably unlikely to migrate as 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.  Perhaps with it being a BizTalk Services feature you might get a monitoring story, which might be richer than what you get with Service Bus Relay.

From a security perspective there are some differences between the products, which are important to note.  The first is the different support for accessing the endpoint.  If you use hybrid connections then it uses SAS but this 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.  Even after you are authenticated to the endpoint there are also some differences.  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.  If you have multiple WCF Services hosted on the same port then this could be a problem.  There may be some application specific security but from a connectivity perspective we can reach all services.  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.  This might be important if you only want to expose a subset of your services to the cloud.

Some of the common scenarios where a customer would expose WCF services to the Azure Service Bus Relay also includes using the WCF routing service to act as the on-premise listener which opens a connection to the cloud via the WCF relay bindings.  This means the customer does not need to modify their existing WCF services to include the new binding.  The customer then uses the WCF routing service to be the on premise listener which can then route requests to multiple on premise applications based on the soap action.  This is quite a good pattern to provide a simple way of exposing services but you can also expand the usage to multiple applications without connecting all of the applications directly to the cloud themselves.  This pattern could also be implemented with hybrid connections but this would require the installation of the software agent for hybrid connections on premise in front of the WCF routing service then the rest of the pattern would work as previous.   I think customers would tend to be put off this approach with it seeming to add extra un-necessary hops.

Finally in the scenarios where you could use either product I think cost will be a key factor.  One of the bits of feedback from the community previews of hybrid connections is that requiring a BizTalk Services package makes hybrid connections significantly more expensive than Service Bus Relay when you consider the usage across multiple test environments and then production.  I’m sure Microsoft will use this feedback and create a better pricing model for hybrid connections because it makes sense that it should be a bit more expensive than Service Bus Relay but it should be purchasable in a cloud friendly usage based model which would make it more competitive than it is now.

I think once the costing is more balanced the decision for scenarios where both products are usable will boil down to these key factors:

1. What do you do already (if anything) for this kind of pattern
2. What ports do you need to use
3. Do you want a tightly coupled point to point integration channel or do you want to be able to have a routing pattern and to take advantage of some of the WCF features

Thoughts for the Future

Hybrid Connections is a really exciting new technology but I think that it will also help to drive improvements for Azure Service Bus Relay.  I expect that the number of scenarios where customers use Azure Service Bus Relay will reduce to some degree.  For many users the Hybrid Connections approach could make things simpler.  One of the things id like to see would be some extensions to Azure Service Bus Relay such as the ability to install an on premise agent which hosts the WCF routing service and is able to take routing configuration from the cloud.  This will make connectivity setup and configuration simpler and mean that a customer doesn’t need to support their own component to do this role.   Overall the number of customers able to do hybrid connectivity in a simple way is going to increase and that’s a great thing.