Thread by @QuinnyPig

I've repeatedly said that if I were going to start a company from scratch today and I didn't have a pile of experience with @awscloud, I'd be hard pressed to choose a cloud provider who wasn't @GoogleCloud.

I stand by that, but let's bound this with the reality that I *do* have that experience with AWS.

If I'm building something for production, where downtime is going to have a real impact to my customers and to my business, it's borderline unthinkable that I'd pick a provider that isn't @awscloud.

This isn't me being a fanboy or a shill, and it isn't a particularly strong endorsement of any provider. The reason for my choice isn't that I know how AWS works – it's that I know how AWS breaks.

"We have Load Balancer X." Good for you. What happens when it fails to, y'know. Balance load?

What does that look like? How can I tell that that's what's happening?

No provider that I've seen talks about this. It's forbidden to even acknowledge that their services might degrade, according to The Book of Corporate Comms.

But everything breaks. I need to know how so I can figure out what I'll do when it inevitably does.

AWS is no better or no worse in this respect than any other provider; I simply have the benefit of a decade of hands-on-keyboard experience with the platform to be able to answer those questions. I know what's likely to fail first, and how I'll know.

I'll still be surprised, certainly! And not the good kind of surprise, either.

I don't know how you'd change my viewpoint on this. But the future of cloud isn't crusty old bastards like me.

Thought experiment. Let's pretend that @awscloud's Route 53 API had a published control plane RTO of 15 minutes and RPO of 2 minutes.

aka "It might rarely be down for up to 15 minutes, with data loss of up to 2 minutes of your last changes."

Would you like that?