LBaaS, VSI, VMwaaS, SAP, distributed databases, cloud storage volumes, cloud security—cloud computing brings a delicious alphabet soup of possibilities to the table when it comes to system architecture. Not just functional parity, the cloud also brings the opportunity for enterprises to evaluate complex new architectural offerings without investing in the infrastructure required. And when in production, it allows them to offset end-of-life/disposal costs through subscription-linked payments. There’s a lot to like. But there’s one word that becomes a fly in this delicious alphabet soup of business opportunity: latency.

Resiliency and availability in the cloud: A latency challenge

The cloud offers the benefit of near-infinite infrastructure but is still limited by geographic distance and time. While resilient systems can be built on the cloud, they will often not pass muster on system requirements due to latency concerns. The most common highly available architecture on cloud infrastructure today is across availability zones (AZs).

A standard across cloud service providers today, availability zones are split across a specific geographic region, often tens of miles apart. This setup typically provides low single-digit latency between AZs in the same region (~2-3ms). This latency is small and does not prove to be a challenge for workloads when the intra-AZ communications is infrequent (such as a monthly backup). But when it comes to high availability and resiliency, this can become a significant challenge.

To illustrate this, let us look at a fictional service. The NeverNeverEver (NNE) service provides a redundant storage platform for cloud customers and services. Store requests first go through to a load balancer that distributes requests evenly across all the zones in use.

The next hop, an intermediate request handling router, manages various tasks like validation and authorization checks, then passing them to a firewall that evaluates the incoming data before passing them through to the storage tier.

The storage tier sequentially replicates the data across the three zones, and once the data is replicated across all three nodes, the data is considered safe and the response flow goes through back to the client/service:

In the figure above, the request may traverse AZ boundaries eight times; more, if the routers or firewalls are configured in high availability mode and one of them goes down. Assuming that the request processing time within the firewall, router, load balancer and the storage tier itself is around 6ms and the inter-AZ request latency as 2ms (slightly above standard latency according to tested figures), the total processing time for the request becomes 22ms.

Reducing latency by 75%+

With IBM Cloud’s new Madrid multi-zone region (MZR), latency between highly available (HA) workloads is no longer a concern. With sub-1ms latency between availability zones, the Madrid MZR allows your high availability, latency-restricted workloads to operate at on-premises speeds. The cloud’s benefits of strong disaster security through geographically distributed AZs is retained, minus the fly in the soup (latency). See the Latency Dashboard below:

Going back to our example—these reduced latency rates between AZs cut down the request processing time to less than 12ms, essentially halving the time needed for each transaction.

Build your enterprise’s high availability, resilient workloads in our newest MZR to achieve true on-premises performance and cloud scale and security—at the same time.

Getting started with IBM Cloud VPC

If you are not already an IBM Cloud customer, it’s easy to sign up and get started. If you are already a customer, you can now provision file shares using the IBM Cloud Console, API or CLI.

Get up to USD 1,000 in credits in VPC infrastructure including networking, storage and compute components by using the code VPC1000 at the time of provisioning or through the billing and usage section in IBM Cloud Console.