Earlier quoted context omitted.
Evan, I just noticed that your service seems to be running on Slicehost, not the AWS colo in Virginia. Is that correct? I got the opposite impression from your post, which seems to imply that Twilio is hosted on AWS, yet managed to weather the storm because of your design decisions.
Our main infrastructure is deployed on AWS but we have capacity at several cloud providers for load-balancing, redundancy, etc.
Why Twilio Wasn’t Affected by Today’s AWS Issues
31–40 of 41 posts
Re: Why Twilio Wasn’t Affected by Today’s AWS Issues
#32Ditto for any web 2.0 we-are-a-fancy-shared-commenting-blog service, or anything that is fundamentally time based aggregation of information. Do database replication systems just not handle the concept of working with temporary gaps in the data?
Re: Why Twilio Wasn’t Affected by Today’s AWS Issues
#33Re: Why Twilio Wasn’t Affected by Today’s AWS Issues
#34I want to see an article about making use of not-perfectly-up-to-date backups databases in a different region. Why can't reddit dump a copy of their new articles and comments to the west coast every night, then if the east coast dies, fire that up? Sure it's missing a chunk of the latest day's data, but that has to beat either completely being down or jumping through the technical hoops required to keep separate regi…
Re: Why Twilio Wasn’t Affected by Today’s AWS Issues
#35Re: Why Twilio Wasn’t Affected by Today’s AWS Issues
#36What percentage of the various pools were affected by the outage?
I'm more curious about the hourly rate.
If you have a pool of 30 instances and only 3 are accessible, are you still being charged for all 30 plus the additional 27 you need to bring up?
Re: Why Twilio Wasn’t Affected by Today’s AWS Issues
#37Earlier quoted context omitted.
Evan, I just noticed that your service seems to be running on Slicehost, not the AWS colo in Virginia. Is that correct? I got the opposite impression from your post, which seems to imply that Twilio is hosted on AWS, yet managed to weather the storm because of your design decisions.
Our main infrastructure is deployed on AWS but we have capacity at several cloud providers for load-balancing, redundancy, etc.
Re: Why Twilio Wasn’t Affected by Today’s AWS Issues
#38I want to see an article about making use of not-perfectly-up-to-date backups databases in a different region. Why can't reddit dump a copy of their new articles and comments to the west coast every night, then if the east coast dies, fire that up? Sure it's missing a chunk of the latest day's data, but that has to beat either completely being down or jumping through the technical hoops required to keep separate regi…
A lot of AWS stuff can't be transferred between regions. There's no way to move an EBS snapshot from east to west coast except to copy the thing across the public internet. Once it's over there on the west coast, to "fire that up" they have to launch app servers, database servers, cache servers, etc. whose configurations they had to keep mirrored from their normal region. They need to get all those backups onto EBS d…
Re: Why Twilio Wasn’t Affected by Today’s AWS Issues
#39I want to see an article about making use of not-perfectly-up-to-date backups databases in a different region. Why can't reddit dump a copy of their new articles and comments to the west coast every night, then if the east coast dies, fire that up? Sure it's missing a chunk of the latest day's data, but that has to beat either completely being down or jumping through the technical hoops required to keep separate regi…
A lot of AWS stuff can't be transferred between regions. There's no way to move an EBS snapshot from east to west coast except to copy the thing across the public internet. Once it's over there on the west coast, to "fire that up" they have to launch app servers, database servers, cache servers, etc. whose configurations they had to keep mirrored from their normal region. They need to get all those backups onto EBS d…
Re: Why Twilio Wasn’t Affected by Today’s AWS Issues
#40This post would be better if they gave more concrete examples of their infrastructure. I read the whole post and still don't know how they survived except some knowledge about distributed system design.
The new rent-a-bike scheme in London has POS terminals connected to the central system via bits of string and/or cellular modems. Every now and again these links fall over or the central system becomes unresponsive.
If you are attempting to get a bike (with an active card subscription) you drop your card into the terminal and it prints you a release code that lets you take a bike.
Unless the system is down... in which case it still reads your card, and then sits there and shows you a spinner for 5 minutes.
You can't walk away during this time, because if you do and the link comes back up it'll print a release code which anyone can use to take a £300+ bike on your account.
If you do stick around and try again? That'll be another 5 minutes which you could have spent walking to the next bike dispensary.
I think that timeouts are one of those things that you can only tune really well when you use the system in a live environment and see how well things work. In this case a higher transaction failure rate would be vastly better than a 5 minute time out - on other systems not so much.