> Of course it's not possible to auto-scale stateful servers like databases
That's not entirely true. :) It's just a lot harder to scale them elastically. At Netflix we've done some proof of concept work on elastically scaling Cassandra, although we don't have it in production yet. I think that is one of our goals for 2013.
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."
Even 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.
I 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.
That's not entirely true. :) It's just a lot harder to scale them elastically. At Netflix we've done some proof of concept work on elastically scaling Cassandra, although we don't have it in production yet. I think that is one of our goals for 2013.