101–110 of 116 posts
Earlier quoted context omitted.
That's 99.97 for the last month . Which is ridiculous, 9s for most services use years as standard. Of course if heroku did that they wouldn't look so good.
It doesn't matter whether gauged by the month or year. It's a percentage. If they have 99.97% uptime every month for a year, they'll still have 99.97% uptime for the year.
#AWSpocalypse
Earlier quoted context omitted.
I just got up (it's morning in Israel), and a client of mine in the US with a major, mission-critical application was screaming (rightly so) that things are down. We're already looking into alternatives -- perhaps not leaving Heroku altogether, but certainly not depending on them 100 percent. There's no way that we can entrust the business to something that can just catastrophically fail at any moment. I've been runn…
> There's no way that we can entrust the business to something that can just catastrophically fail at any moment. Anything, including service providers, can catastrophically fail at any moment. Fault-tolerant architectures are based on redundancy (including infrastructure provider redundancy, as you mention), not on "guaranteed" SLAs.
The AWS status page[1] is showing problems for EC2 East as of a few minutes ago. This might be is a more widespread issue. EDIT: Various non-Heroku EC2-East-based sites (e.g. Quora) seem to be down as well, lending more evidence to this being an EC2/EBS outage. 1: http://status.aws.amazon.com/
They posted an update on amazon: We continue to investigate this issue. We can confirm that there is both impact to volumes and instances in a single AZ in US-EAST-1 Region. We are also experiencing increased error rates and latencies on the EC2 APIs in the US-EAST-1 Region. Also Amazon Relational Database Service (N. Virginia) is unavailible. Seems like its snowballing.
Earlier quoted context omitted.
Isn't it your fault you didn't build a fault tolerant application? The first rule of building services is assume everything is broken.
Honestly, I haven't the resources to guarantee site uptime, and have accepted this will happen as a result; my complaint was more targeted at the default error messages. It seems this can be changed, though, fortunately for Heroku.
Everyone should take a page from the book of Netflix right now. It's pretty embarrassing to be anyone that's entirely down and can't do a thing about it due to an EC2 outage. How do you explain to your customers/users/etc that you were down and have absolutely no control of when you will be back online? How can you explain it to yourself?
"We're sorry about the current downtime. We know some of you are frustrated, so we thought we'd take a moment to explain why this happened. "Running a web server is very expensive. After we've built the site, if we want to keep it running, someone needs to be on-call 24 hours a day. That means at least one full-time staff member who does nothing else-- more if we want them to stay sane. "To save us and you some money…
Related: Right now when I try to cat /proc/mdstat or use mdstat to look at my RAID status, it just hangs. Seems it's trying to contact the EBS volumes and it's just failing. Any way to actually view my raid status?
It's probably best not to muck around with the RAID right now when the drives it thinks are there aren't actually there. If it were me, I wouldn't touch anything until Amazon fixes itself.
Earlier quoted context omitted.
"We're sorry about the current downtime. We know some of you are frustrated, so we thought we'd take a moment to explain why this happened. "Running a web server is very expensive. After we've built the site, if we want to keep it running, someone needs to be on-call 24 hours a day. That means at least one full-time staff member who does nothing else-- more if we want them to stay sane. "To save us and you some money…
Yes, it's actually easier to apologize to your customers when you have AWS to blame for the outage. After all, you're in good company ("even Heroku is down - what do you want from us?")