3 ms·
Theoretically, there's going to be a state of affairs where it's not possible -- that's physics. Maybe with multi-host tenant, so that we're not relying on AWS
by thezilch 14y ago
Theoretically, there's going to be a state of affairs where it's not possible -- that's physics. Maybe with multi-host tenant, so that we're not relying on AWS networking / control-plane screwing with what is going to be the most important part of that dance.
But this is about saving money; not being a tenant of multiple providers; not spending more than "2 weeks."
- stonemetal 14y agoEven on a boring old DB: Spin up a few read slaves, give them a few min to sync to current, turn them loose. Sure it is only read scalability, but every bit counts.
- thezilch 14y agoI think you're missing the point that I'm not going after the DB layer or your own software states (eg. read only). Most AWS outages are related to network layers; you have to already be sync'd. If you want to do writes, sync'd enough to still guarantee a quorum for your writes AND reads, and if the AWS network(s) are fractured enough, you could theoretically be without access to bringing up a stable "wan" for yourself. And then you may simply be hamstrung by ELB outages and be left without hope altogether. If we're talking about read-only, I don't see why a DB, in the traditional meaning, has much to do with the issue. These are not necessarily AWS faults; they are certainly trying to help. It might be the year for being a tenant of more than one PaaS though, but that is only going to up your costs and still not give infinite 9s.