41–50 of 85 posts
Ideally, under normal conditions, your 'active' landing pages should be as fast as your static maintenance page.
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…
Here's a small, shameless, open source, plug: I work on the "Cactus" static website generator, check out and fork our work here: github.com/koenbok/Cactus (current version), https://github.com/krallin/Cactus (next version)
(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…
Do you guys have any plans to actually show the results of the DNS changes based on health checks? Connecting the health checks to cloudwatch is a great start, but it would be really useful to actually see which of my rules are in effect at any given time.
So you can already use the CloudWatch "average" statistic to get some limited visibility. Here's the metric for my own personal micro instance (hosted in us-west-2) ; http://failfast.info/micrometric.png .
When the average drops to 0.875, what's actually happening is that one region couldn't reach us-west-2. (It turned out to be a transit networking issue somewhere between Singapore and Oregon). Just to give a sense of how rare partitions are; that's the first and only time I've seen one affect my instance, and I've been using the feature before we launched publicly.
But yes, we would like to add visibility into things like where it seemed to fail from and whether it actually impacted any DNS decisions (in this case it didn't, as even our nodes in Singapore were able to tell that my endpoint was healthy, via redundant data from other regions).
Edit to add: I should add that the most common reason why a health check fails is that the endpoint is just unhealthy, or totally unreachable. There is absolutely no ambiguity in those situations and the CloudWatch metrics tell you exactly when the failure and recovery happen. Only crazy internet partitions are hard.
Earlier quoted context omitted.
Here's a small, shameless, open source, plug: I work on the "Cactus" static website generator, check out and fork our work here: github.com/koenbok/Cactus (current version), https://github.com/krallin/Cactus (next version)
Is the new version stable or would you recommend the old one to a newcomer? I'm using Hyde right now, but I'm not loving it.
It's got more tests, and it succeeds at building the Cactus examples like the old one. The only thing that's not stable in it is the "serve" mode.
I'm working with Koen (the original author) to get this into the main repo.
--- If you use it, and run into any issue, get in touch with me: thomas [at] orozco.fr
A drop-in solution to achieve the same is using CloudFlare as CDN for your website. CloudFlare has a configurable "Always Online" mode that is automatically triggered whenever your site is down, that shows the user an offline version of the website, together with a warning message. Obviously, if you're using CloudFlare in the first place, chances are that you won't have too many problems with high peaks of traffic an…
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…
The other man says, "Your site doesn't work on my browser with NoScript."
These two men will never like each other.
Route53 is also an excellent DNS service.
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…
A drop-in solution to achieve the same is using CloudFlare as CDN for your website. CloudFlare has a configurable "Always Online" mode that is automatically triggered whenever your site is down, that shows the user an offline version of the website, together with a warning message. Obviously, if you're using CloudFlare in the first place, chances are that you won't have too many problems with high peaks of traffic an…
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.
Earlier quoted context omitted.
Do you guys have any plans to actually show the results of the DNS changes based on health checks? Connecting the health checks to cloudwatch is a great start, but it would be really useful to actually see which of my rules are in effect at any given time.
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…
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 together (short of polling ELB IP changes every minute which doesn't really work out that well).
