On February 19, my colleague Edward Haletky wrote a piece on scale. In it, he highlights that scale is not just about 20,000 desktops and 3,000 virtual hosts. Rather, there are many other metrics that could and should be considered with regard to scale.
I am currently living in Perth in Western Australia. Perth holds a rather dubious record in that is it is the most remote capital city in the world. “Wait, Canberra is the capital of Australia,” you might say, and you would be correct. However, Australia operates in a federal manner and is made up of states and territories, and Perth is the capital of Western Australia. Why am I saying all this? One word, really: cloud. Living in Perth, our nearest AWS, Azure, and GCP zones are in Sydney, 3,300 kilometers (2,000 miles) away on the east coast. Oracle Cloud? Again, Sydney. OVH? Yes, Sydney. Softlayer? Wait, it has a zone in Melbourne, but that is still 2,700 kilometers (1,700 miles) from Perth. As you can see, we are quite isolated. Physics rather than doctrine limits Perth’s access to public cloud.
The average round-trip latency between Perth and Sydney is 39.7 ms, and that is on a good link. Realistically, it is often higher. This is not good for latency-sensitive workloads. The infrastructure of Australia is poor. It is not uncommon for last-mile communications to still meander along at sub–10 Mbps speeds. nbn™, Australia’s fibre broadband, which promises to bring 100 Mbps to the home, is delayed and often fraught with difficulties and poor marketing. Also, its method of charging for connections is bizarre in the extreme: yes, connectivity is charged based on the data utilised. It is true that it does have unlimited plans, but they are very expensive in real terms.
All this put together makes cloud a hard sell, but that does not mean that it is a bad sell. It is just not the nirvana that it may appear in other more-developed counties.
Considerations need to be given to access to reliable communications. Perth’s primary employers are mining and drilling companies; again, a very toxic environment for cloud computing–based solutions.
The image below shows Western Australia (WA). The areas outlined in red are the major population centres with reliable communications. Much of the area outside the red is uninhabited bushland that makes Alaska seem like Fifth Avenue, New York, on New Year’s Eve. That is where the mines are. There is no guaranteed connectivity. Prospectors use satellite phones, and the working mines have their own discrete mobile communication deployments with private LTE provided by mobile communications towers or TETRA, and, if they are lucky, a private fibre link that costs millions to deliver. As you can see, this is quite a hostile environment, and that is not taking account of the fact that the vast majority of mines are in the northern part of WA, which is a desert.
What would help with a migration to cloud-delivered services in WA? Notwithstanding poor infrastructure outside of the metropolitan areas, there are things that can be done to stabilize long-distance communications between endpoints and cloud providers.
Diverse routes to the Internet are the most logical answer. However, this brings other issues into play. An MPLS network (whether privately owned—yes, WA has privately owned MPLS networks—or managed by a Telco) coupled with a mobile/satellite connection can and does provide stable connectivity. Still, the management of the always-on applications that are utilized in mining is problematic if one link fails. There are outages due to new route discovery. This is why these companies are still front and centre with on-site infrastructure.
Nevertheless, the lack of stable networking infrastructure can be mitigated. This is where SD-WAN can come to the rescue. We recently posted about VMware’s acquisition of VeloCloud, a provider of a SD-WAN product, as an enhancement to its Network Services Business Unit and flagship product NSX.
VeloCloud has a concept called Dynamic Multipath Optimization (DMO). This is the aggregation of all outbound links into a single bonded pipe, where the network decides the most optimal path and uses it, but failover is automatic and seamless. Correct—this is not purely an SD-WAN concept. Citrix can do this with its NetScaler, and so can other vendors. What I like is that this is integral to VeloCloud’s product, not a costed add-on.
This alone will not solve bandwidth or latency issues; it just helps with resilience. DMO is really route optimization, not packet optimization. For packet optimization across a WAN, you need an accelerator. However, there is one major downside to caching. In today’s cryptoaware society, the majority of traffic is encrypted, and for a packet optimizer to function, it needs to analyse the traffic flow to see which packets have passed through it before. This means the device will need to decrypt and encrypt the data flow, significantly increasing the latency to the application. This is unacceptable in today’s environment. Unfortunately, that is a fact in modern enterprises and also for SaaS-delivered applications. HTTPS, SSL, and TLS are monarchs in WAN transportation.
But wait, is it not true that SD-WAN provides encrypted overlay tunnels between branch offices and data sources? Yes, it is, so there is the ability to have the traffic monitored and optimized. Don’t throw your Expands and Riverbeds away yet.