Hacker News Reader

Comment by abalone | Hacker News Reader

Ummm.... they're hosting on HEROKU?

In 2011, Tumblr was down for 42 hours.

In 2011, Heroku was down for 76 hours in one incident alone.

And that's all before you get to the hubris of the assumption that your custom coded setup will perform better. A more sensible argument would be to move to a host with a better proven uptime record, such as Blogger (nearly 100%).

Sources: http://allthingsd.com/20111215/tumblr-had-42-hours-of-downti... https://status.heroku.com/incident/151

View on HN

The 'one incident' was the AWS outage that brought much, much more than Heroku down, and their post-mortem was fairly impressive, as far as that sort of thing goes.

I'm not saying you don't have a point, but imo your comparison of Heroku's 76 vs. Tumblr's 42 is not apples-to-apples. I think you have to at least put an asterisk by the 76. What OP is complaining about is a early-Twitter-days-like unreliability over a long interval, not a one-time outage that has a single explanation and for which Heroku took completely responsibility.

For my part, at the moment at least, I still have more confidence in Heroku than Tumblr, 76 vs 42 notwithstanding.

https://status.heroku.com/incident/151

The quoted down time for Tumblr is site wide. Sites are often down for non site wide times. I know from experience. Don't host on Tumblr unless you're MG Siegler and Tumblr will put you on a priority pool that goes down much less.

No biggie, I can temporary move our blog to another host with a simple DNS change and pulling the static site from our repo. Ah, the power of jekyll!

If you're using Jekyll, why not just host with S3/Cloudfront?

I had thought about it but

- I wanted to use Sinatra to 301 old tumblr urls

- Call me weird but I loathe seeing *.html in urls and that's the only thing you can do with S3 root object (when I checked a few months ago)

- something I can't remember. maybe it was cf edge server time to update when altering updates.

> I loathe seeing *.html in urls and that's the only thing you can do with S3 root object

You can configure name of index file, and that will be displayed for requests against root URL and subdirectories (such as blog posts) as well. No need for having .html in URLs.

The only problem I've encountered with S3 web hosting is that it does not let you host naked domains.

Naked domains as in "example.com" without the www? Just name your bucket without the www and it will work. You can then do a javascript redirect from a simple index page at www.example.com (google has said that they now follow javascript redirects. My play example "http://whitewatersearch.com

Where's the subtle flaw in this suggestion?

OK, here's a hint: we're talking about where to host besides Heroku because of Heroku's 76hr outage last Spring...

Last hint: Heroku itself is on top of AWS...

OK that was actually the answer.

I wonder how many hours would pass before you caught this and set up a new server? What if you're on vacation?

Honestly there's a little bit of "because I did it myself and I'm awesome it won't fail." That's hubris and very typical of young engineers.

Letting someone else manage it for you is probably the right thing for a startup to do. You just need to choose someone with a good, proven uptime record. That is what should guide your decision.. with so many things in engineering.

For a more fair comparison, I'll point out that the "skynet" Heroku outage you cited would have caused roughly 16 hours of downtime for the particular type of application used by the OP (a static site with no database), not 76.

Jekyll requires deploys to publish new content, and deploys were down for 76 hours. So, partial outage.

My point is if uptime is your goal you should go with a proven solution. Relying on an unproven custom setup to be 100% mistake free smacks a bit of young engineer hubris.

Reply on news.ycombinator.com