XtremeCloud Multi-Cloud Applications
Understand the unparalleled resiliency of Eupraxia Labs Multi-Cloud Applications
It’s a cold hard fact: Multi-Cloud won’t work without data replication. Without data replication you cannot remove or eliminate Disaster Recovery (DR)/Continuity Of Operations (COOP). Removing DR/COOP is exactly what Eupraxia Labs can do with its XtremeCloud Applications.
There are consequences to moving to the cloud and here’s one of the biggest: moving all your data and applications to a single public cloud provider represents the type of vendor lock-in that you have spent years avoiding. When you are selecting one, and only one, Cloud Service Provider you are selecting one vendor.
If you can replicate your data across public cloud services or virtual private cloud services, then you are eliminating cloud vendor lock-in. How? Simply because you can employ cloud service arbitrage, reverse auction (think of the Service Providers like eBay in reverse), and follow-the-sun scenarios which allow you to only staff the day shift with your own people. The bottom line is that you run your application in the cloud that provides the best cost with the most acceptable SLA with the availability and consistency that you are looking to achieve.
Welcome to multi-cloud implementations provided by Eupraxia Labs where bi-directional replication software is a key enabling capability, coupled with cloud-native applications that leverage it, to avoid vendor lock-in. Many CSPs define multi-cloud as a cloud solution between on-premise and their own public or virtual private cloud (VPC). We offer a cross-cloud solution that provides a true Active-Active experience. In other words, we provide a homogeneous application that is operating completely independent between sites. The only linkage between the sites is the metadata and the data that we replicate over low-latency Cloud Service Provider (CSP) interconnects or on-premise data centers to CSP backbones. We refer to this cross-cloud traffic, in the aggregate, as the XtremeCloud Data Grid. This data grid must be monitored and managed, along with proactive alerting, to ensure its integrity. By integrity we mean to achieve as close to CAP as possible. CAP is discussed below, in more detail, in the Background section.
Let’s discuss what we mean by CAP. The CAP theorem applies to distributed systems that store state. Eric Brewer, at the 2000 Symposium on Principles of Distributed Computing (PODC), conjectured that in any networked shared-data system there is a fundamental trade-off between consistency, availability, and partition tolerance. In 2002, Seth Gilbert and Nancy Lynch of MIT published a formal proof of Brewer’s conjecture. The theorem states that networked shared-data systems can only guarantee/strongly support two of the following three properties:
Consistency - A guarantee that every node in a distributed cluster returns the same, most recent, successful write. Consistency refers to every client having the same view of the data. There are various types of consistency models. Consistency in CAP (used to prove the theorem) refers to linearizability or sequential consistency, a very strong form of consistency.
Availability - Every non-failing node returns a response for all read and write requests in a reasonable amount of time. The key word here is every. To be available, every node on (either side of a network partition) must be able to respond in a reasonable amount of time.
Partition Tolerant - The system continues to function and upholds its consistency guarantees in spite of network partitions. Network partitions are a fact of life. Distributed systems guaranteeing partition tolerance can gracefully recover from partitions once the partition heals.
In the 19 years since its introduction, designers and researchers have used (and sometimes abused) the CAP theorem as a reason to explore a wide variety of novel distributed systems. The NoSQL movement also has applied it as an argument against traditional databases. We could not disagree more with the NoSQL movement with respect to CAP. We have senior data architects and senior enterprise architects, with decades of experience, that have envisioned and implemented a way forward. The rules have changed in this era of highly available clustered databases, scalable cloud-native applications, and reliable low-latency interconnects.
With highly scalable cloud-native applications and cluster databases with a shared cache architecture implemented by Eupraxia Labs, quite simply, Disaster Recovery (DR/COOP) is no longer required and the three properties of CAP are manageable. The anxiety is gone. The scalability and inherent reliability is unequaled. The challenge may exist, but so does the solution.
It is not uncommon for an organization’s users to be denied access to a CSP’s environment. When that happens, businesses are being unproductive and often-times a business operation grinds to a halt. In these days of cloud-native applications and low-latency Virtual Private Clouds (VPC), this is intolerable.
Traditional active-passive designs for Disaster Recovery (DR/COOP) have a complex testability problem that will often offset the challenges of active-active designs like the ones found in XtremeCloud applications.
Determining whether the passive CSP region, or secondary data center, is actually ready to handle traffic can only be accomplished by sending traffic to it. That could be a really bad time to found out that the backup, or secondary, site is not ready for live traffic. In an active-passive design, you will be unavoidably impacting your users or customers by sending them to a site that is not ready. We challenge anyone to cite a situation where this did not prove to be true in a datacenter failover scenario. Multi-cloud active-active implementations, like XtremeCloud from Eupraxia Labs have an inherent self-proof of suitability for handling mission-critical traffic without disruption to business operations.
The suitability of multi-cloud active-active implementations is not achieved without significant challenges, but at Eupraxia Labs we’ve architected and implemented this self-proof and we will unveil the engineering details to you.
Let’s start with the Concept Of Operations for our XtremeCloud Single Sign-On (SSO) cloud-native application.