Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Honestly, if you're a big service that millions of people use, you should not put all your eggs in a single basket and should probably use a mix, in case one of the clouds goes down like in this case.


One of the biggest reasons you go for a cloud is because you don't want to deal with reliability & scaling issues, and there's a premium price attached to that. I think most companies using S3 in this case believed they put their eggs in different baskets when they put their data in there.


I can't believe anyone would have thought a dependency on a single AWS region, or even single service provider, would count as having eggs in different baskets, at least, I really hope nobody could think that!

I suspect though that most people affected deemed the risks and costs of failure low enough to be acceptable, and for many people it still is - even with this outage. But that's a conscious decision, rather than plain ignorance.


That depends if you're willing to pay for the cost of hosting all your content twice and the development overhead of managing that. Twice the persistences means twice the chance of an issue occurring.


That's where tech like kubernetes help in making your app/service portable. Or having common APIs like between s3 and google cloud storage.

Twice the persistence means always having at least one backup and thus the occurance of downtime reduces not up


With containers, I think the devops overhead would be minimal.


That's if _everything_ is in containers. Also, don't undermine how much of a difference the host machine configuration can make... Docker uses its kernel.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: