To take advantage of cloud arbitrage across public clouds (dynamically running workloads in whichever cloud best meets your needs at a given time) you need to continuously compare their pricing and performance.
This demo shows one way you can measure the relative performance of the big three public clouds in real-time. It consists of one application running on-prem that simultaneously publishes requests to identical responder applications running in each of the public clouds. The publisher tracks how long it takes each subscriber to respond and displays this response time in milliseconds.
The request-response pattern is a fundamental building block of many applications and systems in how they communicate with each other. It appears across use-cases and industries. This demo features a request-response scenario where the publisher periodically sends one message to multiple subscribers (sometimes called "fanout") and each of those recipients sends a response back to the publisher, which then makes the result available for you to see.
The time taken for the request message to reach the 'London, UK' datacenter of each cloud provider.
The speed and bandwidth availability of each provider's inter-region network links.
The CPU speed and availability of the server running the responder program.
We've attempted to eliminate variables on the test side of the equation (such as the geographical 'region' of the datacenter and the configurations of the server running the responder programs) so our results indicate the performance of the remaining elements such as network and processing speed. The response time is therefore taken to represent the holistic performance of the running responder application, with all the infrastructure variability factored in.
The results show round trip time from the local UK node of each cloud, and from their respective nodes in Asia and the US, specifically Singapore and Virginia, respectively.
If we look at an example result like this one, you can see that for messaging between the Solace on-prem datacenter and each cloud provider's UK datacenter, the fastest interaction at that time was with Google Cloud.
If you are looking to do more than just "within UK" messaging, selecting Google exclusively does not offer the fastest option because messaging between the UK datacenter and another cloud datacenter in the US-East region was fastest with Azure Cloud. Since the 'first hop' to the Azure UK datacenter was not the fastest of the three, that means their connection between UK and US is fast enough to overcome that slow start.
Similarly, for messaging between UK and Singapore, when I ran this test AWS Cloud was the clear winner, 20 milliseconds faster than Azure Cloud, and 240 milliseconds faster than Google Cloud.
Note that shortly after that, the tool reported that AWS slowed down significantly for that path, and Azure Cloud was fastest. This is a great example of how keeping options open with a multi-cloud strategy can help you achieve the best performance in all circumstances.
Join in with the conversation and comments here. Alternatively you can email me or any of your usual Solace global contacts with any questions.