Hacker News Reader

Comment by yunwal | Hacker News Reader

I'm an infrastructure engineer that has never considered using a comparable cloud provider unless the solution I was looking for wasn't supported by AWS. It used to feel like AWS cared about it's reputation and trustworthiness, and now they clearly do not.

If I was starting a project from scratch now, I'd certainly explore other cloud providers, which is not something I would've said 3 years ago. Their blatant lying is definitely going to cost them in the long run.

View on HN

When did AWS lie? On their status page? That's the last place to receive updates on service status. It sucks but it's also common knowledge. I'll give you a little insider knowledge: The SHD is updated manually. If it's any consolation, GCP does the exact same thing.

I saw notifications in the AWS Personal Health Dashboard pretty very early into the issue. Did you see something different?

Also, I've seen issues logging into the default console a lot, so I keep one of the backup endpoints bookmarked. Might come in handy for you too!

https://us-east-2.console.aws.amazon.com/

If you do not design your cloud resources to be vendor-independent, that’s on you. You absolutely need the ability to cross vendors in short order, whatever stack you’re running.

This is easy for the Monday morning armchair QB to say, but the fact of the matter is that most SMBs are not in a position to run multi cloud. Legacy pre container pre kube workloads (tech debt) exist, as do persistent data stores that are too large to replicate between clouds without racking up massive transfer costs. Not even getting into vendor lock-in around networking or things like dynamo or serverless. “Well just move all your stuff to Kube then!” Ok fine, mr CTO, I’ll do it but I’ll need about 3 engineers at 175k and budget a couple mil more in Op Ex. the reality of the matter is that most of us will just gear for MTTR and hope that Amazon takes some lessons from the incident.

Reply on news.ycombinator.com