Earlier this year our company decided, that we will go cloud-all-in within the next few years. And since we are already using a lot of other cloud services from Microsoft (SharePoint Online, Exchange Online, Azure AD, Intune, ...) we picked the Azure Cloud as our host.
And like in every bigger migration project, there will be a migration phase, when parts are already in the cloud and other parts are still within the corporate network. And somehow they need to talk to each other. So we had to come up with a solution.
And these are the options, we came up with:
- Virtual Private Network
- Azure Express Route
- Azure Application Proxy
- Azure Hybrid Connector
Virtual Private Network
The first and most obvious option is a VPN. And it is a viable option, if it wasn't us, who wanted to use only Platform/Function as a Service (PaaS) and no Infrastructure as a Service (IaaS). If we are going to change something as fundamental as on-prem/cloud, we are going the full length. So no VMs in Azure!
Well, it turns out, that VPN needs at least one VM, so no VPN for the DevOps.
Express Route
For those who never heard of Express Route before. It is basically like a VPN, but with a lot more bandwidth and a higher price tag. It basically prolongs the Corporate Network into Azure. And drumroll it works with PaaS. But you need to configure every single PaaS-Application, every single Azure Database. And instead of the solution we were going at last, it couldn't be done by us DevOps but some Network Team.
Not the way we wanted to go. We needed to be able for fast changes. And we don't even know, where the Network people were located.
So no Express Route for the DevOps, either.
Azure Application Proxy
The Azure Application Proxy allows you to make Http(s) to call into your Corporate Network. So basically this restricts us to REST calls for our APIs.
You will need two endpoints:
- On premise, install a service, that opens a connection to a relay service in Azure.
- In Azure, you configure an Endpoint, that relays calls to the same relay service, which then forwards it to the connection already open from your OnPrem-Endpoint.
It works only for Http(s), but we could have created a relay web service for our database queries. With Serialise.Linq we could serialise our EF-Expressions and send them to the server in a rest call, which calls the DB and returns the result.
Overall, it works pretty well. We also have full control ... BUT:
With Azure Application Proxy, you basically have an open Endpoint of your intranet page/API in the public internet without any further authentication. You can use Pre-Authentication, to have every call to it authenticated with OAuth2.0 against your Azure ADFS, but I never managed to get this to work in code. I always ended up on the page, that prompts you to enter your credentials, instead of my corporate endpoint.
Maybe I am holding it wrong, but since I needed access to our asset management system, that was not nothing I wanted open in the public internet.
We have the Application Proxy in use at our company, but not for the DevOps team.
Azure Hybrid Connections
Let's come to the reason for this article is there in the first place. The information about it is a bit sparsely on the internet. I just found it accidentally and maybe it is for you as well.
I was looking for the bazillionth time for any solution to our VPN-PaaS-Problem and then I found this site.
I saw this
and I was thinking: "This is exactly, what we need!".
It works almost like the Azure Application Proxy, but ... and this BUT is the important part. It is protocol agnostic... So it forwards basic TCP connections, allowing you to access your on premise database.
You need again two endpoints.
- On Premise the relay service
- Configure a URI to catch and forward. (Catcher)
Configure the Catcher to your App Service/Function/... and just use the same URI as if you were in your local network, with a small addition. ALWAYS give the full URI including the port.
So for a database connection it would be tcp://yourDbServer:1433.
Whenever you access the resource in your code, the catcher will forward the request to your on premise endpoint, where it is resolved, accessed and the result returned.
You do not have an open endpoint in the public internet, because you need to configure it for every single web application you are using it in. But then you could use the same code as on premise.
One caveat: It seems, that you will need at least a premium Application Service Plan to use Hybrid Connections. So that's about 100€/month, but they are really worth it!
Did I miss something obvious or not so obvious?
Oldest comments (0)