Yesterday, I was assigned to fix a nuget package solution that was not packing all the needed files. I had a bad time searching online for answers, and had to dig in by myself. After I discovered how to include the files that I needed, I decided to create a simple tutorial that has it all!
This tutorial will show you how to include your non-compilable items into a nuget package (nupkg). This steps apply to any type of file.
Create IT as an Internet connection of 100mbps Down/20mbps Up. Azure was capping at a 150mbps symmetrical connection.
TeamViewer VPN, Azure Site-to-Site and Point-to-Site connections were capped at 10mpbs.
And when all testing’s complete… A final review is coming! So, brace yourselves and let’s start with a graph ?
Note: 5MB results must be multiplied by 10 (value x 10)
Here are the results. All of them. Don’t forget to multiply 5MB results by 10!
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.
In this test, we’ll be using Function Apps and Logic Apps. Function Apps are a serverless concept of running custom code in Azure. Serverless is capable of scaling when needed. We deployed this C# function that represents the Client Application (but without GUI).
This function calls our REST Web Service (On-Premises) via Point-to-Site VPN connection to Azure. This can be called on-demand via URL, via Run button on the image, or via Logic Apps.
In this scenario, the client makes one single HTTP request, instead of 10 requests as previous scenarios.
Point-to-site. PTS for now on. PTS is a way of connecting single clients (machines) to a gateway in Azure, without connecting the entire infrastructure to it. In this case, you only need a client computer, instead of an enterprise router. The client machine connects directly to Azure via VPN.
Will this be faster that Azure Site-to-Site?
Starting with a real-world application of Azure (it’s used here on Create), this scenario is a direct 24/7 VPN link to a gateway in Azure. This is a business-oriented solution. The whole on-premises network is connected to a whole network of devices in Azure (only the ones associated to this VPN gateway obviously).
Consider it as an extended office, with VMs and Azure Functions running outside your premises, as if they were there right next to you! It’s the future.
We’ll be using the same messages, as well the same service-client logic (Via HTTP GET). Instead of using TeamViewer VPN or exposing our service, we’ll use a secure VPN connection to a gateway, that has one VM that’s running the client app associated to it.
This scenario is based by direct HTTP connection via exposed web service, accessible without VPN. This can be a very common situation nowadays too, as it’s just like a website or a web API, and it’s cheap! VPN connections can be the main cause of delays between two points. A secure tunnel brings delay into the equation by itself.
We’ll be exposing the REST Service (on-premises), and connecting the client application via HTTP (Azure), transmitting the same messages as previous tests.
In this scenario, we’ll keep it simple. This is the full on-premises scenario. You must worry about maintenance and power bills, and I’m not even counting on infrastructure costs (high-end routers, switches, cabinets, etc.).
The machine with the service is running via Ethernet cable, while the client machine is running via Wi-Fi. This is the most common connection scenario nowadays.
We’ll do 10kb test for initial values and escalate to 100kb and 5 MB. These messages are the same as the previous test scenario (test #1 TeamViewer VPN).
Test #2 10kb message
With a 10kb message, it took ~6ms to run, for each message. Even with peaks of -10ms, it’s much faster than previous scenario with the same message. This dues to proximity and LAN connection advantages. It’s a short way between them. No need to route packets for miles. Bandwidth is a crucial factor here. To exceed a 1gbps LAN connection, you need a large file travelling through, and that’s not the case here.
First test – TeamViewer VPN
In this first test, we are connected via TeamViewer VPN (specification of this technology at the last post) to an Azure VM (Virtual Machine). This VM is running Windows 10 retail version, with Visual Studio 2017 installed. Visual Studio is used to change the requests made to the OnPremService, to have more precise results. We are also using Edge browser from Microsoft to run client web app.