Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Twilio Wasn’t Affected by Today’s AWS Issues

twilio.com

Post reply on HN
Print view View original

21–30 of 41 posts

Re: Why Twilio Wasn’t Affected by Today’s AWS Issues

#21

Post by aaronblohowiak »

emcooke wrote: post #15
toast76 wrote: post #6

504 Gateway Time-out nginx/0.9.2 You really want to make sure your shit works before you go boasting about how well it works. :) EDIT: seems to be working now :P Interesting article once I got over the irony of it not working.

Ironically, this highlights one of the main issues we discuss in the post! The Twilio Engineering blog is hosted off an external Wordpress site with a single IP that's forwarded from ngnix load balancer pool. Since the load balancers assume that the external service can fail, they won't tied resources blocking access to other parts of the site. Hope you enjoy the post :) -Evan Twilio.com

Why not stick an angel-mode Varnish in between? Serving stale blog is usually better than no blog!

Re: Why Twilio Wasn’t Affected by Today’s AWS Issues

#22

Post by chadrs »

johndyer wrote: post #20
dmor wrote: post #17

Earlier quoted context omitted.

yep, our blog is hosted on a third party service completely unrelated to our website and APIs

dmor, really? It looks like the blog points to AWS, as does your API? jdyer@aleph:~ [git:master] » host api.twilio.com api.twilio.com is an alias for public-vip374d1ca4e.prod.twilio.com. public-vip374d1ca4e.prod.twilio.com is an alias for ec2-174-129-254-101.compute-1.amazonaws.com. ec2-174-129-254-101.compute-1.amazonaws.com has address 174.129.254.101 ---- jdyer@aleph:~ [git:master] » host www.twilio.com www.twilio…

DNS lookups don't tell you anything here. The way a reverse proxy works is that HTTP requests to certain URLs get turned into an HTTP client request by the web server to the 3rd party provider (for caching, URL changing, compressing, terminating SSL, and get around firewalls). You can learn about them here: http://en.wikipedia.org/wiki/Reverse_proxy

Re: Why Twilio Wasn’t Affected by Today’s AWS Issues

#23

Post by emcooke »

aaronblohowiak wrote: post #21
emcooke wrote: post #15

Earlier quoted context omitted.

Ironically, this highlights one of the main issues we discuss in the post! The Twilio Engineering blog is hosted off an external Wordpress site with a single IP that's forwarded from ngnix load balancer pool. Since the load balancers assume that the external service can fail, they won't tied resources blocking access to other parts of the site. Hope you enjoy the post :) -Evan Twilio.com

Why not stick an angel-mode Varnish in between? Serving stale blog is usually better than no blog!

Yup, good idea. We set up an ngnix proxy to cache the page while the blog hosting provider fixes their server.

Re: Why Twilio Wasn’t Affected by Today’s AWS Issues

#24

Post by johndyer »

chadrs wrote: post #22
johndyer wrote: post #20

Earlier quoted context omitted.

dmor, really? It looks like the blog points to AWS, as does your API? jdyer@aleph:~ [git:master] » host api.twilio.com api.twilio.com is an alias for public-vip374d1ca4e.prod.twilio.com. public-vip374d1ca4e.prod.twilio.com is an alias for ec2-174-129-254-101.compute-1.amazonaws.com. ec2-174-129-254-101.compute-1.amazonaws.com has address 174.129.254.101 ---- jdyer@aleph:~ [git:master] » host www.twilio.com www.twilio…

DNS lookups don't tell you anything here. The way a reverse proxy works is that HTTP requests to certain URLs get turned into an HTTP client request by the web server to the 3rd party provider (for caching, URL changing, compressing, terminating SSL, and get around firewalls). You can learn about them here: http://en.wikipedia.org/wiki/Reverse_proxy

True, and I had actually misread dmors' post entirely here; I read the post as stating Twilio's blog was not reliant on AWS in anyway, which would have been a misrepresentation in my mind. However in hindsight this was not the case, and I will certainly admit when I am wrong.

Re: Why Twilio Wasn’t Affected by Today’s AWS Issues

#25

Post by jdupree »

trotsky wrote: post #13
johndyer wrote: post #5

LOL...."504 Gateway Time-out".....nginx must not be one of Twilio's "small stateless services" (F)(A)(I)(L) ;)

A cursory inspection indicates that their ngix box at least is running on EC2 NoVA. It takes a particular kind of person to want to tempt fate to such a degree by posting something like that while running on top of what can be best described as "a fluid situation"

Like saying "My spelling is perfect, my grammer to!"

Re: Why Twilio Wasn’t Affected by Today’s AWS Issues

#26

Post by oinksoft »

emcooke wrote: post #15
toast76 wrote: post #6

504 Gateway Time-out nginx/0.9.2 You really want to make sure your shit works before you go boasting about how well it works. :) EDIT: seems to be working now :P Interesting article once I got over the irony of it not working.

Ironically, this highlights one of the main issues we discuss in the post! The Twilio Engineering blog is hosted off an external Wordpress site with a single IP that's forwarded from ngnix load balancer pool. Since the load balancers assume that the external service can fail, they won't tied resources blocking access to other parts of the site. Hope you enjoy the post :) -Evan Twilio.com

Speaking of highlighting, something about Disqus' markup/styles causes your blog text to be un-highlightable with mouse (Firefox 3.6.16 Debian 5.0.8).

Re: Why Twilio Wasn’t Affected by Today’s AWS Issues

#28

Post by markerdmann »

emcooke wrote: post #15
toast76 wrote: post #6

504 Gateway Time-out nginx/0.9.2 You really want to make sure your shit works before you go boasting about how well it works. :) EDIT: seems to be working now :P Interesting article once I got over the irony of it not working.

Ironically, this highlights one of the main issues we discuss in the post! The Twilio Engineering blog is hosted off an external Wordpress site with a single IP that's forwarded from ngnix load balancer pool. Since the load balancers assume that the external service can fail, they won't tied resources blocking access to other parts of the site. Hope you enjoy the post :) -Evan Twilio.com

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.

Re: Why Twilio Wasn’t Affected by Today’s AWS Issues

#29

Post by dmor »

oinksoft wrote: post #26
emcooke wrote: post #15

Earlier quoted context omitted.

Ironically, this highlights one of the main issues we discuss in the post! The Twilio Engineering blog is hosted off an external Wordpress site with a single IP that's forwarded from ngnix load balancer pool. Since the load balancers assume that the external service can fail, they won't tied resources blocking access to other parts of the site. Hope you enjoy the post :) -Evan Twilio.com

Speaking of highlighting, something about Disqus' markup/styles causes your blog text to be un-highlightable with mouse (Firefox 3.6.16 Debian 5.0.8).

Thanks for the heads up, I've disabled Disqus comments for now... was also causing some issues for iPhone/iPad readers. Regular commenting is enabled

Re: Why Twilio Wasn’t Affected by Today’s AWS Issues

#30

Post by emcooke »

markerdmann wrote: post #28
emcooke wrote: post #15

Earlier quoted context omitted.

Ironically, this highlights one of the main issues we discuss in the post! The Twilio Engineering blog is hosted off an external Wordpress site with a single IP that's forwarded from ngnix load balancer pool. Since the load balancers assume that the external service can fail, they won't tied resources blocking access to other parts of the site. Hope you enjoy the post :) -Evan Twilio.com

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.
Post reply on HN