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.

Azure plans

In Azure, the most economical plans were chosen, considering our requirements. Some plans were free, some were cheaper than the others, but having VPN capabilities and all configurations supported, we chose the cheaper plans that were available with all these needed features supported.

Browsers

We used Chrome, Firefox and Edge. This was to eliminate browser differences. Not showing any differences in total execution times, we kept using Chrome as a default testing browser.

LAN Connection

Lan wise, our internal network is based on a 1gbps Local Area Network.

On-Premises Service Host

The On-Premises Service was hosted on a machine running Windows 10 Retail with latest updates installed and IIS Express. All code was made with Visual Studio 2017 Enterprise. The relevant host hardware specifications are:

1. Intel® Core™ i7-6700HQ CPU @ 2.6GHz
2. 32GB of RAM DDR4 @ 3400MHz
3. NVMe M.2 PCI-e 240GB SSD

Testing Hours

All tests were executed on working hours, 9am to 18pm, GMT.

The Writer

I’m a consultant @ Create It, a Portuguese company. If you read this, make sure I know about it! ? Hugs and kisses! This was an absolute pleasure to make ?

The post Latency test between Azure and On-Premises – Specifications appeared first on Blog IT.

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!

With the graph below, we can check how message sizes influence latency. After doing some math, these are the results:

As we can confirm, latency follows an exponential growing rate, which means, the bigger the message, even greater will be latency. We can confirm that, for each scenario, this applies.

But what does it tell me? This tells you that you need to be careful if you’re planning on sending big messages between two points. This exponential growing rate applies to all scenarios!

All values listed and noted, so we gave tests a score. This score is calculated by adding all three results (10kb, 100kb and 5mb) and dividing all by three. This will give us average execution time. For your best understanding, below is an exponential graph. This climbs faster and faster to infinity, being the horizontal axle message sizes, and the vertical one latency:

Now for the results!

As we can check, Test #2 (Local On-Premises LAN) was the winner here, latency wise. This was expected. Although this is the fastest, it’s the riskiest and NOT RECOMMENDED! It’s true that latency is reduced, but with only ~53ms difference between Azure Site-to-Site on a 100Kb message, is it worth to have a full infrastructure depending on your maintenance? And the networking gear it requires? What about having someone responsible for the room 24/7? How about costs? Think about it! Think about savings when migrating your business to Cloud!

Second place goes to HTTP without VPN (Exposed services). Not a Cloud solution, and a risky one too! If you like hackers messing with your vital business services and trying to break in from all over the world 24/7, go right ahead!

Regarding fast and safe Cloud solutions, which is the main reason of reading this document after all, the winner was Test #4 (Azure Site-to-Site VPN), getting third place on the board, by a difference of 8 points! This managed to be the safest, more efficient and with 99.9% uptime method of expanding your office or network, and have a low-latency data exchange. This is the optimal and safer solution. No hackers, no maintenance, no worries!

Consult us to migrate your business! You’re at the doorstep to your future!

For full test specifications, read here!

The post Latency test between Azure and On-Premises – Conclusions appeared first on Blog IT.

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.

After saving which connection you want to use, you can always confirm connection status in this window:

But wait, I see Service Bus referenced in that print screen! What’s that?

Service Bus is a technology of asynchronously sending and receiving messages from multiple publishers to multiple subscribers. This is, as you’ve probably guessed, a publish/subscribe mechanism.

This is an example of a publish/subscribe architecture. The image should be self-explanatory. A sender sends a message, and all subscribers have filters to only process the messages that they subscribe to.

Why didn’t you test this method?

Well, before you call me anything, you got to understand why.

Architecture!

This concept relies on checking the bus for new messages from time to time, with a 10 second interval for instance. Each 10 second, your program/service, or whatever you want to call it, will check the bus for new messages and retrieves them. This generates a “waiting game”, that’s why it’s called an asynchronous process. It’s not designed to be fast, but to be reliable and to connect multiple services into one giant message box.

Example:

A highway. A highway in USA connects multiple states together, and you can choose where to leave it. You can choose a city in a certain state, or a totally different city in another state, it just depends where you’re going to. This is the same. The service bus it’s like that highway. A publisher publishes a car. Each message (car) has a topic (destination), and every subscriber (city/state) retrieves a message (car) depending on their topic (destination).

This is the main reason that latency doesn’t apply here. It’s a very robust and clean way of integrating services with applications, but latency isn’t a concern here. It’s just not made to be fast. It’s made to be simple.

Conclusions and summary next post!

The post Latency test between Azure and On-Premises – Part Seven appeared first on Blog IT.

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.

Important note:
In this scenario, the client makes one single HTTP request, instead of 10 requests as previous scenarios.

This is a Logic App (Designer View). We start by a Recurrence Action, which is a timer set to run each 30 second. When recurrence action is fired, this logic app starts by calling “HttpTriggerCSharp1”, which is the function app showed previously. When this function app is finished, the logic app sends an e-mail to my Create account reporting total execution time.

Finally, this is the e-mail that is sent by our logic app. We can see that total execution time reported by the function app is 63ms. Read on for full results!

Test #6 10kb message

Called by a Logic App trigger, the client makes a HTTP request to our On-Prem Service, receiving a 10kb message, the same as before.

We can see that total execution time was 59ms. This is measured by calling the function app via Run button. We’ll be doing this due to being easier to obtain results. This same result is reported by mail if the function is called by Logic Apps. Execution time oscillated between 47ms and 70ms, being the median value ~59ms. Not bad, and slightly faster than TeamViewer VPN, but slower than direct HTTP request without VPN.

Regarding this same result and comparing it to Site-to-Site VPN, we can see that this method took more ~15ms to execute. This can have a very important influence if you are choosing between PTS and Site-to-Site for your business. Also, Site-to-Site has a more constant flow, while this test was more irregular (had more peaks).

Rest assured that this method works, if you can trade a slight latency increase over cost.

Test #6 100kb message

Now for 100kb message, we’ll repeat the same steps to obtain the results.

As we can verify, the test took 78ms to execute. It peaked 97ms and drops to 68ms. Overall, it took more ~8ms to execute than Site-to-Site but was ~22ms faster than TeamViewer. Regarding direct HTTP request without any VPN, this was slower ~17ms. That’s quite a punch there. Let’s try 5Mb.

Test#6 5mb message

Now to the ultimate 5MB test. No more words needed here.

We can see that this is a deal breaker here. The latency here is way over any other test we did. 3.8s! This may happen due to several reasons, the main ones being:

1. Function App performance not meeting our requirements,
2. The way that Azure connects PTS VPN to Function Apps,
3. Consuming a large data might be doing some memory swaps server-side.

Overall test discussion

Well, this is very surprising. Function Apps is clearly not the way for a large message. The processing is inefficient, therefore takes way too much time. PTS connection to a VM in Azure was faster by more than one second, and surprisingly cheaper!

This solution may still be in Preview, or may have bugs, or maybe it just wasn’t made for this type of usage. Regarding complexity, is clearly simpler to use than a VM, it’s serverless and scalable. You can get rid of VM and make your functions directly accessible via any web browser on any platform.

For exposing your logic in a cleaner, faster way, this is what you need. For data crunching or analytics, it’s also the cleanest way, but if you’re planning to use it to make HTTP requests to your on-prem services, you should consider other options, unless execution time isn’t on the equation.

Read the next post here about relays and service bus!

The post Latency test between Azure and On-Premises – Part Six appeared first on Blog IT.

Will this be faster that Azure Site-to-Site?

Test #5 10kb message

10Kb is our base message. PTS didn’t show any issues regarding this one.

Execution time is practically the same as before (on Site-to-Site scenario), with the same message size. 1% is not noticeable on a large batch execution. Let’s see for 100KB. If results change more drastically, then we can analyze and find a reason for this.

Test #5 100kb message

We didn’t see a big difference before. Will 100kb be the game changer?

Actually, it is! It’s ~10ms faster than before! Site-to-Site is beginning to lose to PTS.

Probable causes are:

1. Router delays due to packet queues (Site-to-Site)
2. Router processing power limitations of encrypting packets (and routing them)
3. General hardware limitations

 We start to see some differences now. ~10ms is a noticable improvement. How fast will 5MB be?

Test #5 5mb message

The ultimate test on PTS.

Well, PTS it’s not for large messages. It’s inefficient and takes a lot of time! You should only use this for a one-time-only scenario, like accessing a VM or downloading some files from Azure. Processing large messages with PTS is not recommended, as execution times increased ~1 second in average.

 Overall test discussion

This is an awkward situation. 100KB is faster than Site-to-Site, but 5MB it’s not. While processing small to medium messages you should be fine. Not recommended for production as it showed to have some unusual peaks, so latency may be compromised.

Go to next test!

The post Latency test between Azure and On-Premises – Part Five appeared first on Blog IT.

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.

We’ll start by doing 10kb, following 100kb and 5MB. Again, this is the most common scenario nowadays!

Test #4 10kb message

Running 10kb of data through Azure VPN Site-to-Site is surely a piece of cake.

It took ~44ms to execute! It’s roughly the same as 263bits through TeamViewer VPN! Using the same 10kb, this test scenario has a reduced execution time of~20ms! Now that’s an improvement. A secure, tight VPN to Azure, site-to-site, with reduced latency! That’s quite a hit in P2P (Peer-to-Peer) VPN connections!

Test #4 100kb message

Well, after seeing a ~20ms drop with a 10kb message, will execution times drop with a message that’s 10 times bigger?

Remember how TeamViewer VPN managed ~100ms on this test? If that’s quick, this is blazing fast! Less ~30ms than P2P VPN solution. Azure Site-to-Site connection is proving to be better than TeamViewer, and only ~9ms slower than HTTP without VPN. Let’s go for 5MB.

Test #4 5MB message

Let’s go through the ultimate test. Can we saturate the Azure VPN connection with this?

Well, that’s astonishing. For a message this size, execution time it’s greater by ~150ms only! Guess that’s the price to pay for a secure tunnel. Direct HTTP execution times are smaller, but considering risk over latency, this is a great and optimal candidate.

Overall test discussion

Well, this did prove me wrong. Initially, I had the idea that TeamViewers’ P2P VPN connection was born to be faster, but it’s not! Azure Site-to-Site is faster, safer, scalable and available to multiple devices, both on Azure and on-premises. Personally, I think this solution is optimal for enterprise integration, as is your business logic needs. For a fast and secure connection to Cloud computing, this is an excellent candidate. It has 99.9% uptime, which is great for 24/7 intensive data crunching or message exchanging.

Proceed to test #5 here!

The post Latency test between Azure and On-Premises – Part Four appeared first on Blog IT.

We’ll be exposing the REST Service (on-premises), and connecting the client application via HTTP (Azure), transmitting the same messages as previous tests.

Starting at 10kb, then 100kb and 5Mb. 10kb, only a fifth (1/5) of an average HTML file. For instance, Google main page size is 392.8 kB in total.

Exposed services. The hackers’ paradise and snoopers’ ocean. A security risk for sure. VPN protects you from all that. It’s a secure tunnel to anywhere.

Test #3 10kb message

After changing port forwarding configurations in our on-prem router, we’re able to expose our REST web service, listening on port 65443 (a random port was chosen). This will be for testing purposes only and will be removed immediately after all testing’s done (for security reasons).

Results are in! It took almost the same time as before (with TeamViewer VPN)! This is amazing, because the VPN we used added no delay whatsoever, at least for this message size! Execution times peaked at ~55ms.

Test #3 100kb message

Now for 100kb of text. Will HTTP be faster than HTTP over VPN?

WOW! Less ~40ms each! TeamViewer VPN is losing ground now! This took ~60ms each for 100kb of data. This is almost half the time that VPN took! How about 5MB of data?

Test #3 5MB message

The ultimate 5MB of text over HTTP. No explaining needed here… Image speaks by itself.

Wait, didn’t TeamViewer VPN take ~1600ms each to execute? This is very surprising, as we start to notice serious delay due to VPN! ~1.2 seconds each is what HTTP takes to execute a request and a 5MB response. If you do the math, for each 10 messages, you save ~4 seconds! That’s a lot!

 Overall test discussion

Well this is a no brainer. TeamViewer VPN didn’t stand a chance here. For 10kb of data, the results are nearly the same. Neither VPN or HTTP (no VPN) struggled with 10kb, but 100kb and 5MB came with a lot of differences. No VPN proved to be faster in larger messages, but VPN provides a safer, encrypted transmission. I call this your decision: Speed over Security. Exposed services are a serious risk, but VPN is a bit slower. In execution time, HTTP without VPN is clearly a winner here.

 Test#4 on the next post!

The post Latency test between Azure and On-Premises – Part Three appeared first on Blog IT.

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).

Let’s start!

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.

In case you’re wondering, we’ve added a Reset index button and batch execution. Why?

New test functionalities for real-world applications

This is the main reason. Batch send and receive messages, calculating median execution times, and getting more real-world results. The reset index button resets the OK button count, to control the number of requests made. It isn’t rocket science. Let’s move on to 100kb.

Test #2 100kb message

Now for a 100kb message. This one took, in average and for each message, 17ms to execute. Peaked ~25ms.

The same message traveled way faster than before, and response times fell. 10 times the size, increasing ~10ms on execution time. Absolutely not bad at all!

Test #2 5MB message

This is the ultimate test. The big data travelling. The worst-case scenario. Whatever you want to call it, it’s the more intensive in terms of bandwidth.

What!? 10 messages, with 5mb, in only ~563ms each? What? That’s much faster than Azure!

Why you ask?

This happens a lot. Local Area Networks (LAN) are usually faster. The connection to the outside world is flooded with data and millions of routers in between. No wonder it takes longer. Which would take longer? Copying a 1GB file from your collegues computer, or downloading the same file from the Internet? Yep, your collegues computer. LAN connection is way faster (via Ethernet, Wi-Fi may not apply, depending on the hardware you have available).

Final overview of this scenario

Well, here we are. At this point, you must be thinking: “Oh, why the hell should I migrate my solution to Azure?”

Let me explain:

1 – Dust!

Your worst enemy inside 24/7 powered on servers. If you are not carefull, it may overheat and damage some components, and all your data or business may stop! You have to do maintenance frequently, or hire someone to do it for you!

2 – Hardware!

Your main hardware concerns. RAID (Redundant Array of Inexpensive Drives) is used worldwide for data mirroring and data safety. This has a high failure rate (depending on your configuration on the array); therefore, you can lose data for good. Resuming, you have Hard Disk Drives, Raid controllers, memory chips, motherboards, NICs, Power supplies… Everything is critical inside a server! You don’t want to be this guy when something fails.

3 – Infrastructure

Cost. It’s written all over it. Power hungry servers are heat sources, so you must have air conditioners to cool them down. The usual monthly cost of a medium sized server room is 1400$, without indirect costs! Everything in this room needs maintenance and, again, can break down. This generates downtime and can be very harmful for your business. You must have people who oversee this room (an employee or an IT company for instance).

Despite these disadvantages, this is the fastest way of exchanging data, the fastest way of sending messages. But… but what?

But it’s not scalable.

Scalability. If your business services suddenly need more CPU processing power, or more RAM, your server might be uncappable of handling it! Physical hardware limitations exist. In Azure, with few clicks, you have all the performance boost you need, with little to no downtime at all!

Replication. Server replication is a clever way of avoiding downtimes. With bigger costs for on-premises, cloud manages this for you out-of-the-box, and it’s cheaper!

“Day-to-day usage of on-premises server rooms is a thing of the past!”

Read on to the next part, Via HTTP GET (without VPN)!

The post Latency test between Azure and On-Premises – Part Two appeared first on Blog IT.

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.

This is a screenshot of the UI of Azure Client App. In this screen, we see an “OK” button and three text fields. This two first fields are going to be populated with the current time (in milliseconds), and the third one with the total elapsed time, also in milliseconds. The first field will be filled with a timestamp, wich is generated when you click the OK button. The second field is filled with a timestamp, but only when the client receives a response from the OnPremService. The third is then populated with the difference of timestamps (second field – first field). This will give us the elapsed time between pressing the button (making a request) and receiving a response (with data from OnPremService).

Here we see the results. The “77” written on the button is the total number of requests made by the Azure Client App. This number is sent by the OnPremService. We can see that this operation took 42ms to execute.

Median values

Above are the median values of total elapsed times. The first one’s higher because the browser needs to render the page and all services are woken inside IIS and internet routes being formed. After the first request, we see that total elapsed times are very consistent, and didn’t have peaks.

This is only for a simple request-response mechanism via VPN. The data travelling inside the VPN is not larger than 263 bits until now.  This makes a absolute minimal “ping-like” test, showing us the real bare-minimum connection latency results.

Test #1 10KB MESSAGE

Now we are going to repeat all those steps, and instead of showing a table with results, we’ll be resuming the results, thus improving the readability.
In this test, we’ll be increasing the response to 10KB (Kilobytes), being 10kb in plain text (shown in the text area below the button), to see how total elapsed time changes.
After increasing data size, the total elapsed time stayed roughly at ~65ms, with random peaks (worst results are roughly between 125 and 150ms). We see an increase of ~20ms.
Not too bad, considering that data size is now ~300 times larger than the base test!

 test #1 100KB MESSAGE

With the same UI and the same functionalities, let’s try to increase even more the data size, to a new 100kb of text (100 times the size as before).
Initial request elapsed time was ~440ms, and right after it, stayed roughly at ~100ms, with peaks of 150ms average. Again, not too bad!

test #1 5MB MESSAGE

With the same UI and the same functionalities, let’s try to increase even more the data size to 5120kb (50 times the size), being 5MB of plain text. This is the last test of this scenario.
Initial request took ~1.8 seconds (1809ms) to execute. This is a quite considerable amount of time, when execution time is critical.
Next requests stayed roughly the same as the initial request, and all sort of spikes were detected. We noticed some requests taking nearly one second to execute, to taking up to two and a half (2,5) seconds to complete. This is more inconsistent because file size is huge for HTTP Get method. Although this might not be a VPN problem, this becomes a very unpractical way of using HTTP for a big message.

Final overview of this scenario

Resuming, this is a very consistent method. If you need to send data repeatedly, in small amounts, this is a great candidate. HTTP methods via TeamViewer VPN proved to be low-latency and very easy to implement, having fast responses to a small data size extent.

Table of average execution times regarding this test scenario and data sizes

Graph of data size vs execution time

In this graph, we can verify that there is an exponential growth of average execution time, when increasing data size above 100kb. Going to 1MB shouldn’t be too bad, but you start to sacrifice execution time over transmitting large data. It’s best to send data chucks and get all together in the client app. Max execution time is very above average. This dues to all services being hibernated and coming back to life takes time. When all is up and running, average times go way down!

Make sure you don’t miss next part!

The post Latency test between Azure and On-Premises – Part One appeared first on Blog IT.

In these series of posts, we’re going to compare different ways of connecting to Azure. We’ll setup a web service and a client. We’re going to see which architecture is optimal in terms of latency, cost and effort. Despite results being very similar, the scenarios are very different between them. The Cloud has multiple ways of integrating your business. Some are cheaper, some are more expensive. We’re here to break the barrier between cost, effort and actual benefits of each scenario. This article was made by analyzing live results, repeating each test more than once, to ensure that no other variables interfere with our results.

 “With Azure, we can rely on our own core competencies, and not have to build the underlying infrastructure.”

Nik Shroff, Director of Microsoft Solutions, Adobe

 

INTRODUCING…

We live in a world that is managed by computers, and IT is improving every day. Humans are creating clever and autonomous ways to manage businesses and citizens private life. Social networks and Cloud storage (i.e. OneDrive) are examples of the huge power that’s available on Cloud nowadays.

Today, people rely on internet to their day-to-day life, from their personal agendas to a “like” on Facebook or a post on Instagram. Businesses rely on computing power that’s available outside, for a fee. This can be cheap if you are running a small business with few transactions. Consider this: Imagine the power requirements and bandwidth that you’ll need to run Facebook servers at home. Could you host billions of people seeing photos and reacting to posts each minute, or even each second? Imagine the huge processing power and data storage requirements… that’s right, you couldn’t!

…CLOUD

Cloud. The thing that’s running behind the biggest companies and technologies. People sometimes think that cloud is an enormous computer with tons of processors, billions of TB of RAM and millions of hard-drives, and all connected to the internet. Wrong. Cloud is a set of multiple computers, replicated all-over the world. When you connect to a social network, in a second you could be connected to a server in Spain, and the next second you are connected to a server in Austria!

Cloud is a clever way to have your processing needs satisfied, without worrying with maintenance needs or millions of dollars in power bills. All inside a cloud is scalable. If your business grows, the cloud plan grows according to your needs, without much effort or services being offline.

In this article, we’re going to explain the technical details and real-world results. How long does it take to process information when all operations are hosted in the Cloud? How long does it take to process the same information when your operations are all on-premises? How can you have the best of both worlds (Hybrid Cloud)?

WAIT, WHAT?? Hybrid Cloud?

Hybrid Cloud? What’s that?

I’ll give you an example. Imagine that you run a start-up of wallet manufacturing. You have few of them and you’re ready to open a store.

Now you are with an open store and wallets to sell. You have a small database and a computer to register clients, to print receipts and to manage sales. In this situation, you have the on-premises solution. All is stored inside your facilities.

Now imagine that you have a boost of sales, you are becoming huge in selling wallets. You have a batch of millions in production plus more millions in stock. You also have wallets all-over the world, in stores, online selling companies like Amazon, etc. You are the Nº 1 in wallets worldwide. Would you still run all information on your computer inside your store? Seriously?

NO! Now, when your processing and data storage needs are huge and increasing every day, you can’t have all of this on-premises, it’s just too expensive and irrational. You feel the need to have a Cloud solution, that is available to all your employees and stores all-over the world. Here’s what you have now:

• You have software in a computer (per-store) that manages the employees and stock on that same store;
• You have a huge database stored in cloud;
• You have all client information in Cloud;

A full Cloud solution is when you have all the above stored in cloud. A hybrid-cloud solution is when you divide and share technologies between Cloud and on-premises. That’s it. Quite simple right?

ACTUAL NUMBERS

Now that all concepts are known, we did some tests to have base numbers to find out if, in a certain scenario, it’s better to have your on-premises solution stored and running in a Hybrid Cloud solution.

Base test

Test Scenario

We have a REST service, written in C#, that is hosted on-prem. This service returns a simple string (for now), with the number of clicks that were submitted by the client web app. This service is called “OnPremService” (for further reference).

We also have a Web App (Web application), also written in C#. This Web App is the client app, the one that calls the OnPremService with a request. This Web App is called “Azure Client App” (for further reference). This web app is running on Azure (West Europe) and available via any browser.

The Azure Client App we’ll be connected to OnPremService in multiple ways:

• Test #1 – Via TeamViewer VPN (with HTTP GET);
• Test #2 – Local On-Premises (LAN without VPN, using HTTP GET);
• Test #3 – Via HTTP request (without VPN);
• Test #4 – Via Azure Site-to-Site VPN (with HTTP GET);
• Test #5 – Via Azure Point-to-Site VPN (with HTTP GET);
• Test #6 – Via Azure Function Apps & Logic Apps (with HTTP GET);

Also, we’ll talk about another way of doing the migration, but is not recommended if latency is an important factor.

• Discussion #1 – Via Relay using Hybrid Connection (Topic) (with HTTP GET);

Read on to part one and start finding out which one’s faster for your needs!

The post Latency test between Azure and On-Premises – Intro appeared first on Blog IT.