No post body was provided.
Untitled topic
1–9 of 9 posts
Re: undefined
#2[deleted]
Re: undefined
#3I don’t believe you dogfood your own service when it’s critical infrastructure. It’s common to use competitor infrastructure for core services so you have fault tolerance if it fails. Ideally your status page is on a separate cloud in a separate region too.
I imagine this is a choice to prevent circular dependencies on AWS within AWS itself.
Re: undefined
#4Probably there are good reasons for this (like avoiding chicken-egg/bootstrapping issues, circular dependencies etc.)
Re: undefined
#5This just seems like common sense.
Anyone remember the Facebook DNS outage when the on call engineers couldnt get into the building to fix it because it took the key card system down too?
Re: undefined
#6This is spam for the Ops service. Please be transparent about your ownership of the dns check service you run. We shouldn’t need to check your profile for that info.
Re: undefined
#7This is spam for the Ops service. Please be transparent about your ownership of the dns check service you run. We shouldn’t need to check your profile for that info.
agree they should have put that disclaimer, but it was useful content nonetheless because they didn't necessarily talk about their tool.
Re: undefined
#8I don’t believe you dogfood your own service when it’s critical infrastructure. It’s common to use competitor infrastructure for core services so you have fault tolerance if it fails. Ideally your status page is on a separate cloud in a separate region too. I imagine this is a choice to prevent circular dependencies on AWS within AWS itself.
That makes sense. But then the idea of a simultaneous failure preventing, say AWS and GCP/Azure, from restarting due to accidental circular dependencies in the init sequence needed to reboot the two competing cloud infrastructure is interesting.
Re: undefined
#9I don’t think it’s that shocking to be fair. They’re using it for aws.com, which is not an insignificant domain.