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

Keep a static "emergency mode" site on S3

coderwall.com

Post reply on HN
Print view View original

51–60 of 85 posts

Re: Keep a static "emergency mode" site on S3

#51

Post by Retric »

EGreg wrote: post #35
Retric wrote: post #16

Earlier quoted context omitted.

You still need to update DNS ASAP, but unless your dealing with a physical flood/fire you can often get something to respond on the old IP. So, depending on the type of failure your dealing with, often setting up a static redirect is viable for insane levels of traffic even if your hosting it off of a single underpowered CPU and limited bandwidth. Aka the site has been running off your FIOS connection and a spare CPU…

Why don't you just always have your site static and connect to your back end as necessary? Treat it as a webservice with uptime, etc.

Because designing V0.1 of your application from the ground up based on edge cases is a Great way to never release anything. Spending a weekend setting up a static failover on the other hand has no long term downside and let's you put off worrining about a host of those edege caeses without any real down side. It's like buying a UPS for your dev box it's probably never going to matter, but it's cheap so feel free.

Re: Keep a static "emergency mode" site on S3

#52

Post by verelo »

aleem wrote: post #50
colmmacc wrote: post #43

Earlier quoted context omitted.

Almost all of the time what you see in CloudWatch should be representative of what's being served. The internet stays consistent to at least four nines. Our CloudWatch metrics are actually made up of 16 independent metrics reporters (2 per 8 regions we run in) - each reporting a 1 or a 0. So you can already use the CloudWatch "average" statistic to get some limited visibility. Here's the metric for my own personal mi…

Not directly related but I have one major gripe with ELB--am hopeful you have some inside knowledge and a possible workaround. I use CloudFlare for DDoS protection which Amazon doesn't offer. For apex domains, ELB requires route53 exclusively but that conflicts with CloudFlare which also requires DNS be hosted there. Since ELB uses CNAME records I haven't been able to find a way for the CloudFlare and ELB to work tog…

You can still use Route53 with Cloudflare by using their cname setup.

This doesnt solve the issue for the apex however, so we have a S3 redirect on the apex.

The key thing this allows us to do is continue to use Route53 with Cloudflare.

Re: Keep a static "emergency mode" site on S3

#54

Post by peterwwillis »

EGreg wrote: post #7

Yeah but the big question is, how can you switch the DNS over in time when NONE of your servers can respond fast enough?

Hopefully your load balancers are still responding and they'll failover to an alternate working site. If not, having multiple load balancers in your DNS round robin config could allow the client to retry another record to see if it works, which is hit or miss in my experience, but others have said it works reliably. Like someone else said, low TTLs help. Or Anycast, or advertising your ASN from a new router/DC. None of that should be necessary as Amazon will take care of that for you, but only if you pay for and configure all the right services.

Re: Keep a static "emergency mode" site on S3

#55

Post by Afforess »

23david wrote: post #49
Afforess wrote: post #45

Earlier quoted context omitted.

replying to 23david, not the parent. 23david you appear to be shadow banned. It seems to be recent, might want to get it checked out.

thanks for letting me know. emailing the mods.

glad it's cleared up. Seemed innocent to me :)

Re: Keep a static "emergency mode" site on S3

#56

Post by twistedpair »

chc wrote: post #46
mayop100 wrote: post #34

Or better yet -- make your entire site static to begin with! This is how our site works (firebase.com). Our entire site is static content that's generated at deploy time and hosted on a CDN. Dynamic data is loaded asynchronously as needed. If a server were to go down, at least all of the static pieces (which is most of the site) would be unaffected. We use Firebase to power the dynamic portions (obviously), but you c…

One man says, "Make your whole site static! Load content with AJAX instead of generating HTML on the server!" The other man says, "Your site doesn't work on my browser with NoScript." These two men will never like each other.

The NoScript man is used to this and his fitted tinfoil hat. If he's more lenient he uses Ghostery to block all 3rd party addons and various cookie blockers to keep out the cruft, but keeps the actual site unperturbed.

Re: Keep a static "emergency mode" site on S3

#57

Post by twistedpair »

adrr wrote: post #48
mayop100 wrote: post #34

Or better yet -- make your entire site static to begin with! This is how our site works (firebase.com). Our entire site is static content that's generated at deploy time and hosted on a CDN. Dynamic data is loaded asynchronously as needed. If a server were to go down, at least all of the static pieces (which is most of the site) would be unaffected. We use Firebase to power the dynamic portions (obviously), but you c…

You still need dynamic "pages". Things like geoip redirection or localization etc. You could in theory load this stuff via ajax, but this doesn't work for search engine crawlers. But i do agree most stuff can be static, you can push json on fragments onto s3 and have the web page fetch them via ajax.

Route53 can do a lot of that localization redirection for you, though not exactly at the geoip level. Other localization redirects can easy be done from JS.

Re: Keep a static "emergency mode" site on S3

#58

Post by twistedpair »

mayop100 wrote: post #34

Or better yet -- make your entire site static to begin with! This is how our site works (firebase.com). Our entire site is static content that's generated at deploy time and hosted on a CDN. Dynamic data is loaded asynchronously as needed. If a server were to go down, at least all of the static pieces (which is most of the site) would be unaffected. We use Firebase to power the dynamic portions (obviously), but you c…

Shameless plug for Google Web Toolkit. Since core design principle is dynamic site generation client side from permutations (i.e. locales and languages) created at compile time, you can deploy the entire thing as static files to S3. That's what I do :)

The only trick is to leave a foo XHR response in your R53 failover so that a running instance of your app can realize the server is tits up and degrade gracefully. For even better caching throw in webapp manifest files too!

Re: Keep a static "emergency mode" site on S3

#59

Post by jedberg »

colmmacc wrote: post #29

(I work on Route 53). As __lucas has mentioned, this can be achieved with Route 53 Failover, which we'd recommend. Route 53 Failover is (hopefully) pretty easy to configure. Just mark your ELB as the primary and enable target healthchecks, and add the S3 website bucket as the secondary. We'd also suggest that you use an S3 website bucket hosted in a different region than your ELB. This should take no more than a minu…

Except that his way all the traffic instantly switches, and your way you have to wait for DNS propagation, which about 15% of the users on the internet will not pick up for over a week.

DNS is an awful way to do failover.

Re: Keep a static "emergency mode" site on S3

#60

Post by methehack »

mayop100 wrote: post #34

Or better yet -- make your entire site static to begin with! This is how our site works (firebase.com). Our entire site is static content that's generated at deploy time and hosted on a CDN. Dynamic data is loaded asynchronously as needed. If a server were to go down, at least all of the static pieces (which is most of the site) would be unaffected. We use Firebase to power the dynamic portions (obviously), but you c…

In theory, I'm super attracted to this model. My only concern is that it puts a lot of eggs in the Firebase basket. And what happens if I need to scale faster than Firebase can handle? Is there a way for me to run an in-house api compatible version of Firebase on my infrastructure and re-point to that? Can I keep a hot-swappable backup in sync? Or can I pay Firebase to do that for me?
Post reply on HN