Alibaba Cloud — A Data-Driven Analysis
First up, this post touches on Brexit politics, peculiarities of Internet traffic crossing the Atlantic, Mo Farrah running the 5000m race, and of course cloud computing.
So if your reading interest falls in the intersection of these sets, do carry on reading and make yourself known with a clap or comment.
> What’s all the hype with Alibaba?
I’m sure you’ve had Alibaba frequently popping up in your feed. It’s a hot topic, covered often in both business and technology news.
Alibaba is China’s online shopping giant that is often compared to Amazon. Just as Amazon has a cloud computing business with AWS, so does Alibaba.
While AWS is the more established player with the largest market share and estimated revenues of $17bn last year, it is the rapid growth rate of Alibaba that is actually making people take notice:
“In 2016 the cloud-computing business of the Chinese e-commerce behemoth grew by 126%, to $675m. Growth is unlikely to slow soon.” — The Economist
“Alibaba Cloud growing like gangbusters, but still far behind AWS and other market leaders.” — Techcrunch
So it’s all about where Alibaba is projected to be in a few years, not necessarily where they are today.
> Alibaba Cloud Launches London, UK Region
Last month Alibaba added to its global network of data centres with a UK “Region” to some fanfare:
A London location launch means they are courting UK businesses in sectors such as public and financial services, where “data localisation” matters. It is also the kind of event that in the current political climate gets inevitably co-opted to mean something more:
“It will be seen as a pre-Brexit vote of confidence in the strength of the UK tech industry which has worried about levels of investment in the run up to leaving the European Union.” — ZDNet
Yay or Nay for Brexit?
I found it interesting that while the new region is outwardly called “UK (London)” like so:
The reality is that under the covers, you can tell that Alibaba saw the UK as an extension of their presence in the EU, with the “ID” of this new UK region being exposed in various places as EU-West-1 :
With the only other region in the EU being Frankfurt, added 2 years ago, it is obvious that this new UK region is more likely the continuation of long laid plans and not a new investment decision taken following the referendum.
Now that’s enough of Brexit talk… Moving on…
> How can we fairly compare Alibaba Cloud with the big three? (AWS, Azure and Google)
Earlier this year I built a demo to describe a way of enabling Multi-Cloud Arbitrage for applications. The idea is to build and deploy applications on an event-mesh architecture layer that allows them to move easily between different cloud providers. Then based on various ‘arbitrage’ factors such as the cost of compute, actual running performance of your application, or even idle CPU capacity on existing provisioned machines, you dynamically move your application to take advantage of those differences across the providers in real-time.
Avoiding “cloud lock-in” and being multi-cloud ready is key to achieving this kind of arbitrage potential and maintaining freedom of choice. This growing desire by enterprises to achieve multi-cloud readiness can also explain IBM’s $34 Billion acquisition of Red Hat:
“The thing about IBM is, we’ve been around long enough to know this is a multi-cloud world.” (Ginni Rometty, IBM CEO) — Reuters
The live demo itself works by deploying:
- Solace PubSub+ Brokers across three regions within AWS, Azure and Google, taking care of inter-application communication in an ‘any-cloud, any-region’ event-mesh architecture.
- An identical Java application on a “burstable” virtual machine type in the same regions of each cloud.
- Finally, a single Java application running “on prem” in a London data centre.
The on-prem application sends request messages that are delivered identically to all the applications running within the three clouds, for which they all process the request and respond back individually.
This setup allows the on-prem application to calculate how long each responding application took (i.e. the ‘latency’ in milliseconds) to process the request and send the response. In effect, determining a “holistic performance” of the responding application that can be compared with its peer in the same region, but running in a different cloud provider. A ranking can then be determined on which application (running in either AWS, Azure or Google) came back first.
Show me the money.
An example result with this multi-cloud and multi-region setup visually depicted can be found below:
The ability to deploy the above applications to identical machine sizes, operating systems, and geographical locations in Alibaba Cloud to match what I have already in AWS, Azure and Google is the first test of maturity and ease of use in this comparison.
Secondly, I can see how the actual application results compare across the 4 cloud providers and whether there are any interesting findings there.
Just deploy it already!
Turns out that deploying the Java application and Solace PubSub+ Broker to Alibaba Cloud was fairly simple. The equivalent virtual machine types and regions selected across the four clouds are available to review below:
> The Internet has a personality too…
The result for Alibaba in the UK was showing approximately 73 milliseconds for the response to arrive back to the Solace on-prem data centre. This latency number is very odd as it’s comparable to the latency of responses received from the US region in the other three clouds — so my initial thinking was that I must have deployed the “UK” virtual machine for Alibaba in the wrong place!
To understand this result, it was time to break out the go-to tool for any network troubleshooting: traceroute.
(For those who are unfamiliar with it, traceroute allows you to see all the hops that make up the total route of your network traffic between your own IP address and the target IP address. )
London to London, the scenic route.
The traceroute results showed that our Internet Service Provider (ISP) was indeed sending the data to the United States first, for it to use an Internet Peering Exchange located in New York, to eventually get to the Alibaba network via the ISP: “China Mobile International Limited”.
What was even more puzzling is that a similar traceroute test to the same Alibaba London server using a different Internet connection from London did not show the same high latency.
All this shone a bright light into the interesting world of Internet traffic routing across different ISPs:
Put simply, as the Internet is really a network of networks, ‘peering agreements’ between these different networks controls how data may pass from one to another. Individual ISPs will have numerous agreements with other ISPs and large organisations with the aim of eventually reaching all parts of the Internet in an optimal manner.
Show me the way to Ali…baba.
When the ISP used by Solace in London is trying to figure out “How do I send data to this Alibaba IP address?”, the result is “China Mobile knows how to get there, and I am peered with China Mobile in New York, so will hand it over to them there.”
If you want to understand this space in more detail, a good write-up is here. If you want to learn more about just how peculiar Internet routing can be, read about the time a single ISP in Pakistan took out YouTube for most of the world here.
Keeping an eye on the mileage.
This experience does raise an important point though: If data locality matters to you, just selecting to use a cloud service in a given country is not the full picture. Unless you are an enterprise that is purchasing private network circuits from your own data centre to the cloud provider, double-check just how the traffic over the Internet is travelling for you and your end-users to those services.
A service you think is hosted in the UK may as well be in a different country as far as network connectivity and user experience is concerned…
> So how does Alibaba compare?
After working with Alibaba Cloud Support and our own ISP to resolve this issue of peering in London, we can finally look at results on a fair footing.
The best way to do this is through the three historical graphs (on the demo page) that are a rolling window on a per-region basis on what order the application responses arrived.
If you imagine a closely-run long-distance race, like the Men’s 5000 metres from the London 2012 Olympics, you’ll notice that even though Mo Farrah won Gold, his position throughout the race varied greatly:
Those graphs can be thought of as the continuous position tracker of four runners, in a race that never ends.
Ladies and Gentlemen, place your bets.
In this contrived demonstration of applications being deployed across on-prem and multiple clouds, and only the fastest response being of interest, you can visually see that at present there is a lot of competition between the four players for responses from the UK and US.
In the UK, responses from AWS and Google are closely vying for the top position. Alibaba and Azure are then in close competition to determine the third and fourth place.
For responses from the applications in the US region, Google responses are predominantly in first place at this point in time. Then there is a lot of competition between AWS, Azure and Alibaba for the remaining positions.
In contrast the results for the Singapore region look very calm and serene when reviewed graphically like this. The positions in the race are very set and not showing a lot of movement. While Google Cloud was often the front runner for the earlier two regions, it is in firm fourth place here.
Alibaba Cloud responses are in third place, trailing behind AWS and Azure.
In summary, no single cloud provider is a clear winner when seen holistically across the three regions. It is also not a surprise that while the newcomer Alibaba Cloud is not taking any top positions yet in these particular results, the competition is indeed fierce for the second or third arrival position. — An apt metaphor of Alibaba’s real-world position perhaps.
> To conclude…
With cloud computing, this is a race with the players expected to change positions throughout as circumstances and capabilities change.
The only real course of action is to pick your favorite runner with the data you have available up to that point in time. Then as things inevitably change, just be ready to quickly pick your new favorite!
That is the essence of multi-cloud arbitrage.
Happy evaluating!
Top comments (0)