Multi-Cloud SaaS Applications: Speed + Availability = Success!

In this blog post, we talk about how to run applications across multiple clouds (i.e. AWS, Google Cloud, Microsoft Azure) using Tungsten Clustering. You want your business-critical applications to withstand node, datacenter, availability-zone or regional failures. For SaaS apps, you also want to bring data close to your application users for faster response times and a better user experience. With cross-cloud capability, Tungsten also helps avoid lock-in to any particular cloud provider.

The key to success for the database layer is to be available and respond rapidly.

From both a business and operational perspective, spreading the application across cloud environments from different vendors provides significant protection against vendor-specific outages and vendor lock-in. Running on multiple platforms provides greater bargaining leverage with each vendor, because they do not have a monopoly on your cloud operations.

Tungsten Clustering is flexible and platform-agnostic, which means it allows me to run across many different environments. You may mix-and-match any and all together (i.e. one or more clusters of 3 nodes each per environment), which means I can have a cluster spanning AWS, GCP, Azure and even include my bare-metal data center. For cost savings, test/dev/etc. can be put on VM's, Docker containers or even VirtualBox.

There are many challenges to running an application over large distances, including network latency for reads and getting local writes distributed to other regions.

Tungsten Clustering provides a cohesive solution which addresses the various concerns when running a geo-distributed application.

Let's look at the various factors, and how each is handled:

Be available

  • (local) - when looked at from a local perspective, this is considered high availability (HA). If the MySQL database, which is handling writes (and reads) should become unavailable, automatically switch to another server with the same information and proceed to serve writes and reads to the application layer with as little down-time as possible.
  • (global) - when looked at from a global perspective, this is called disaster recovery (DR). Should an entire site, region, availability zone or even cloud become unavailable, allow another site with the same information to serve writes and reads to the application layer with as little down-time as possible.
  • (global) - the Tungsten Replicator is cluster-aware, which means that in the event of the complete loss of a remote node to obtain data from, the Replicator is able to automatically switch to another source node and pick up where it left off.
  • (global) - the Tungsten Connector is cluster- and site-aware, and is able to route both read and write requests to both local and remote resources. When the Connector is installed directly on an application server, a Multimaster cluster topology can withstand the loss of the entire database layer at one site by redirecting reads and writes to another region.

Respond rapidly to requests

  • (local) - by using the failover replicas as read sources, we are able to offload the requests from the master, freeing up valuable resources on the master (i.e. CPU, memory, disk I/O, network bandwidth, etc.). This has the double effect of increasing performance on the write master and improving response time for reads.
  • (global) - employing active/active multimaster clustering, writes to each region are replicated to all other regions. This then makes the data available for local reads, so the database layer is able to respond much more quickly to requests for specific data which otherwise would have to be fetched from a remote site over the WAN, adding precious milliseconds to every query.
  • (global) - the built-in Tungsten Replicator provides loosely-coupled asynchronous data transfer both to local read replicas as well as to all remote sites. Given that WAN connections sometimes have high latency and even complete disconnects, the Replicator is able to track every event, pause when the link is down and resume when the link becomes available.

All of the above facets combine to make a polished diamond of a solution, fit for your company's worldwide enterprise-quality deployment!

If you are interested in running a proof-of-concept, please contact us now!

About the Author

Eric M. Stone

Eric is a veteran of fast-paced, large-scale enterprise environments with 35 years of Information Technology experience. With a focus on HA/DR, from building data centers and trading floors to world-wide deployments, Eric has architected, coded, deployed and administered systems for a wide variety of disparate customers, from Fortune 500 financial institutions to SMB’s.

Add new comment