Why You Need a Multi-Cloud and Multi-Region Deployment Strategy for Distributed Postgres

When I sat down to write this article and create the associated material needed for the videos, I ran into some technical challenges. I had provisioned three cloud providers in three separate regions to simulate multi-cloud and multi-region deploys.

But I couldn’t get one of the regions to behave as I expected when provisioning the environment. As it turned out, the region (and by association, cloud) was down. Worse than that, the provider was experiencing issues related to an undersea cable cut and estimated multiples of weeks until the outage was mitigated.

Ouch.

Fortunately, for demo content, there are plenty of clouds in the sky to choose from, but the importance of multi-cloud redundancy highlighted was particularly poignant. If this had been a production environment and my only deploy region, I wouldn’t be wanting to talk about it right now.

In this post, we’re going to look at some of the reasons you choose multi-region and multi-cloud deployments, whether for resiliency or regulation, and see how Hasura lets you hide all the nuances of these deployments behind its generated API abstractions.

The first reason to choose either multi-cloud or multi-region environments, to begin with, is for data resilience. When our data is in a single region or on a single cluster, there is simply enough anecdotal evidence at this point that you will experience data failure. If you want to keep the data lights on 24-7, you need a mitigation strategy. These strategies fall into two buckets: multi-region and multi-cloud.

We first need to define the differences between multi-cloud vs multi-region. The architectures are simply the implementation details of how we plan for one vs the other. However, depending on your database provider, those details can represent a significant time investment, which we’ll look at later on.

Multi-Region

With multi-region, we deploy our applications to (typically) geographically distributed regions around the world. However, regional deploys are subjected to physical faults. Inclement weather, political unrest, acts of foreign or domestic terrorism, and other physical variables have all led to regional outages in the past.

In practice, regardless of cloud, the regions tend to have exposure to similar physical faults. Instead of simply losing your data, we can switch over to another region to handle the workload. For as much as our industry hates latency, it is alway preferred over loss.

Deploying to multiple regions allows for failover handling. If the Sydney region goes down, the Singapore region may still be online. It would be a globally bad day if the same physical faults impacted Frankfurt, Sydney, and Seattle at the same time.

Multi-Cloud

Physical faults are only one of the types of problems that public and private clouds encounter. User error, poorly configured networks, and other more banal errors can have substantial consequences that impact entire clouds, either from the provider or the user itself. In these circumstances, regional failover won’t help you. An expired certificate, accidental deletion, or disabling the wrong port will take you offline from Seattle to Sydney. If that happens, someone, somewhere, is most definitely awake, and noticed, and will likely not be very happy.

Choosing a multi-cloud configuration protects you from these types of faults so that if Google is having interruptions, AWS is still online, or IBM, Deutsche Telekom, OVH, or Hetzner.

The right answer: have both!

Multi-region is a go-to method to mitigate against mostly physical faults. Multi-node clusters in each of those regions handle general data corruption or failures on a more granular level.

Multi-cloud is a go-to method to mitigate configuration or software-level faults, which are not that uncommon.

The right answer is to have a blend of the two, working within operational cost constraints and general survivable requirements from both regulatory and business objective use cases. I do want access to my heart-rate data from two years ago. The order of browsing across Amazon shopping is of less importance.

While the blend is the right answer, this still doesn’t address the logistical overhead of managing multiple cloud providers' APIs (Terraforms and Pulumis of the world try to solve this use case) or the ability to automate roll-backs and health checks.

We’ll look into that in a later section.

Apart from data resiliency, most companies serving a global market are subjected to a number of geopolitical influences as well. Most users will be familiar with the GDPR regulations ensuring European data stays on European soil. Further regulations require the ability for government oversight to request data at will from service providers, which requires its own set of reasonable isolation from those not in those jurisdictions.

Using a multi-region database provider allows companies to ship single binaries of software without creating isolated applications for different countries. A practice that was the norm not too many years ago.

Performant reasons for multi-region architecture

Retention and regulation aside, in many cases, you simply want a better experience for your users. If you watched the video above, you’ll see just how much latency region separation can introduce. It goes without saying, but the less copper your data has to traverse, the faster the experience will be for your users. Co-locating data and access provides the optimal pathway for getting a user’s data to the end destination.

And it’s not just the individual user’s data. Imagine a sales enablement platform where an account executive needs to manage all APAC or all of EMEA. If these accounts are optimally stored for reads on geo boundaries, you can often remove seconds of delay between page navigations for your account manager. And we all know how much account executives like to click.

At this point, you should be well-convinced of the benefits for multi-region and multi-cloud deployments. But at what cost? Creating replication, failover, logging, and synchronization mechanisms is a non-trivial ask. Even with deployment tooling, it is still a major operational lift to coordinate all the pieces for just multi-region deploys, let alone multi-cloud where variables in APIs come into play.

While shipping horizontally scaling playbooks or helm charts with Pulumi provisioned hardware is a strategy, many of today’s distributed Postgres providers simply come with all these functionalities baked in.

Choosing a single provider that deploys across regions and clouds means you get to benefit from their collective experience while reducing a major burden.

For some quick how-tos on connecting Hasura to Yugabyte or Cockroach, check out our documentation or the following videos.

Or, why you might not need Kubernetes.

Having a database provider offer on-click multi-region deploys is the way to go, but you still need to handle the data access layer. The role-based access, federation, and other settings that enable your developers still need to be distributed along with the underlying data sources.

Using the Hasura metadata approach, it’s actually quite simple to deploy the same configuration for horizontally scaled Hasura instances, leaving you to pick your geo router of choice to distribute the request to the nearest point of presence.

Closing

Hopefully, you’ve seen just how approachable a resilient, distributed data-access layer is by using the right primitives and full-powered providers. If you have any questions on how to activate these patterns in your own setup, we have solutions engineers that are happy to help.

Thanks for reading.

Ready to get started for free with Hasura Cloud? In just a few clicks and no credit card required, create or connect your own database today.