4 ms·
sorry but that seems really naive. an SLA is not a guarantee of service -- you can't force a computer or network to stay online because someone with a sheet of
by unshift 15y ago
sorry but that seems really naive. an SLA is not a guarantee of service -- you can't force a computer or network to stay online because someone with a sheet of paper said so. it's a target for a best-effort guarantee and when that guarantee is broken then you get a bit of a refund.
it's like when you have a big building project and there's a provision that the contractor will refund $5000/day for every day past march 1st. doesn't mean march 1st never gets passed.
failure modes in the cloud are known too: your VMs are either working or they aren't, or maybe they're somehow degraded but you should fail over anyway. it's very similar to physical hardware. what will you think when a backhoe takes out your datacenter's fiber for 10 hours? that physical hardware and datacenters are now unreliable too?
as for a database that runs on a system that offers no guarantees -- isn't that all of them?
- justinsb 15y agoTotally agree that SLAs are not a guarantee of service - I don't believe I said they were, and I was trying to make the exact same point: too many people treat them as if they were a guarantee, even when they carry only token penalty clauses. Separately from the SLA, technical promises/guarantees that AWS did make e.g. isolated AZs were broken in the April outage. I think that your proposed model ("machine is online or not") may be sufficiently simple that the AWS cloud can satisfy it; however I think it is very difficult to build anything interesting if that is the only axiom you have. In particular, I would want something related to persistent storage in the model, or else storing state becomes very difficult.