Avoid Vendor Lock-In Risk with Multi-Cloud Deployments

Re:Avoid Vendor Lock-In Risk with Multi-Cloud Deployments by occultist_throw on Wednesday October 04, 2017 @02:23PM (#15402912)

The trend Ive been seeing is "AP with eventual C". It comoes down to the idea that we have a planet, with datacenters in locations on said planet. Light down fiber or copper only goes so fast.

The "eventual consistency" part is simply acknowledging that we can't beat C when our databases are in North America, South America, Europe, Africa, Australia, and Asia. One-way comms takes time. 2 way comms, even more so.

The tradeoff is, that changes can come in, and 'eventually' will propagate to the rest of the DB nodes. It does sound not ideal initially, however this type of operation would allow a localDB running as AP to sync when back online.

The examples I'm deriving come from recent DBs, like GUN http://gun.js.org/#step1

[ Parent | on HN ]

Re:Avoid Vendor Lock-In Risk with Multi-Cloud Deployments by dastbe on Wednesday October 04, 2017 @03:30PM (#15403712)

cockroachdb and spanner are "CP with high probability of A". There are situations where the db (or possibly a subset, haven't read too deeply into the papers) can become unavailable due to a loss of quorum, but these situations are highly unlikely.

[ Parent | on HN ]