Live data from Hacker News

Keep a static "emergency mode" site on S3

coderwall.com

71–80 of 85 posts

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

#71

I would pay for someone to take care of this for me. I presently run a GH Pages static blog but would like complete control of the build. I want to upload a .zip somewhere and have things just work.

Mentioned it further down in the thread, but working on a really easy way (http://www.bitballoon.com) to get a static site online and backed by a CDN (and we do support uploading a .zip).

What kind of control do you feel you lack when using GH Pages?

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

#72
post #59

Earlier quoted context omitted.

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.

To your point ; it's ok to do both. Route 53 supports DNS TTLs as low as 0 seconds. ELB and S3 endpoints both have 60 second TTLs. My experience with flipping names like www.amazon.com doesn't reflect the 15% figure. I've seen about 97% of web traffic honouring the TTL and flipping quickly. Within 5 minutes almost all of the rest too. We also take CloudFront sites in and out of service for maintenance, and in 5 years…

I don't know that I have ever seen a straggling DNS update take a week, but I have seen many take 3-4 days. Particularly Mediacom customers. I think this situation has improved some, but I still would not consider DNS failover very reliable.

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

#73
post #62
post #51

Earlier quoted context omitted.

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.

Actually it's a great way to simultaneously design a website AND an api for others to use. It's also a great way to separate concerns. It's also a great way to reduce load on your server. In fact, it's an easy way to have some people code a standard back end with a standard authentication so that some other people can make front ends for the web, iphone, and more. You can use, for example, oauth to authenticate with…

I dont't think we are quite on the same page, having an public API etc is wonderful but let's use a slightly different topic. Using some 3rd party ORM to talk to your database is generally a no brainer, but v0.1 might not even have a database yet because persistence is not generally needed for a demo. Why put off such a core feature, because just changing your objects is less friction so and the goal is to see if anyone is ineested. aka idea validation and nothing else.

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

#74
post #69

Earlier quoted context omitted.

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.

True tinfoils don't use propietary software.

It'll be open source soon. Plus, you can always look at the injected JS yourself - it's not obfuscated.

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

#76
post #59

(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.

In your experience, are there still major ISPs that don't respect DNS TTL?

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

#78

(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…

The current R53 health check does not support SSL endpoints, which is rather critical for our use-cases. Please make it happen, thanks.

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

#79

> As far as I'm concerned, S3 static file website serving is completely indestructible. I only need one bland Apache server to bump requests over to it. Is this generally the experience of everyone here?

Nothing you can do is going to take S3 as a whole down, and it doesn't appear to have EBS dependencies so it generally dodges the bullet when AWS has troubles. I'm not aware of any significant S3 outage in the last five years.

One would hope not... With the API they offer it should be the type of service that is reasonable easy to make pretty much indestructible.

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

#80
post #71

I would pay for someone to take care of this for me. I presently run a GH Pages static blog but would like complete control of the build. I want to upload a .zip somewhere and have things just work.

Mentioned it further down in the thread, but working on a really easy way ( http://www.bitballoon.com ) to get a static site online and backed by a CDN (and we do support uploading a .zip). What kind of control do you feel you lack when using GH Pages?

I want to use clojurescript on the page, (which has a compilation step), and I don't want to track the build output in source control.
Post reply on HN