Live data from Hacker News

App Engine down

code.google.com

71–80 of 139 posts

Re: App Engine down

#71

It's time we remembered the whole strength of the internet was that it was distributed and we avoided introducing single points of failure. We have ended up using vast amounts of infrastructure for no reason other than developer convenience (often with respect to security), when having local direct connections is often more suitable than shooting everything into the cloud.

Which is better? Having a day of downtime each year, or not launching at all?

Which is better? Using a fallacious comparison to suggest cloud computing is the only viable option, or comparing the pros and cons of different computing models to choose the best one for you?

Re: App Engine down

#72

Meanwhile... Gmail etc are working quite fine. So the claim that if you build on GAE you "take advantage of the same infrastructure used for Google services!!" starts to ring a bit hollow.

Maybe they mean == instead of ===.

Re: App Engine down

#75
post #40
post #17

I think this is larger than just GAE. http://internettrafficreport.com/namerica.htm It seems like large portions of the internet are down.

Internet Traffic Report, while a nice concept, is unfortunately very misleading. Their sample size is extremely small, and most of those are permanently down. Have a look through their list of north american routers and find one of them where packet loss has gotten worse as their main overall graph for packet loss would suggest - I've just been through them all and couldn't find one.

Their baseline values are very misleading.

But their relative metrics can still be useful.

For example, it's very inaccurate to say that 51% of the internet is down.

But it's precise to say that packet loss among the working nodes has increased about 30% in the last 24 hours, and sharply.

Re: App Engine down

#76
post #63

Meanwhile... Gmail etc are working quite fine. So the claim that if you build on GAE you "take advantage of the same infrastructure used for Google services!!" starts to ring a bit hollow.

I wonder if anyone ever believed this claim to be true...

Or if the definition of the word 'same' is somewhat fluid enough to get away with it

Re: App Engine down

#77
post #12

I'm really happy I don't host in the cloud. How quickly are the cost savings of cloud computing obliterated by PR, customer service, and system administration time when an outage like this occurs?

My colocation provider (Frontier, telecom in 27 states) went down for an hour and a half last night. It's hardly unique to the cloud.

Re: App Engine down

#78
post #70
post #30

Earlier quoted context omitted.

It's funny, i've got the exact opposite reasoning : it's those moments where i can really appreciate the fact that i'm using the cloud : 1/ I don't have to spend the night debugging or replacing broken hardware 2/ It doesn't cost me any time, any additional resource, any support upgrade, any hardware. 3/ No one can blame me or anybody in my team for the fact that it's not working. I don't feel like i'm lacking contro…

If you have paying clients, they WILL blame you and your team for the fact it's not working. They don't care who/what the underlying infrastructure is. Also a good hosting company will handle identifying/fixing/replacing bad hardware for you.

Not to mention sufficient redundancy will ensure that you never see many effects from those hardware failures/power outages/floods/fires/anything else with any reasonable probability.

"The cloud is great because I can blame someone else" is obviously a tenuous argument.

Re: App Engine down

#79
post #57

Earlier quoted context omitted.

We're coloed across three datacenters spanning the US (one might be in TO I think) and if a datacenter were to go down, we have a hot backup that's no more than 12 hours stale. The only real manual maintenance that we've got is a rolling reimaging of servers based on whatever's in version control, which usually takes a few hours twice a year, but we'd probably do that if we were in the cloud anyway. When you can scri…

But a DNS based failover is still going to take an hour or so to propagate right (given that a lot of browsers/proxies/DNS servers don't respect TTL very well at all)? And then you end up with a system with stale data, and the mess of trying to reconcile it when your other system comes back up. I'd take an hour long Appengine outage once a year over that anytime!

Your name server or stub resolver is what respects DNS TTL, not your browser or proxy. Everyone - including people hosting on AWS - needs to be able to fail over DNS, if the AWS IP you're using is in a zone that just went down, for example.

Any time you have an outage you need to contact your service provider to get an estimate of downtime. If they can't give you one, assume it'll take forever and cut the DNS over. The worst case is some of your users will start to come back online slowly. If you don't cut over, the worst case is all your users are down until whenever the service provider fixes it, and you get to tell your users "we're waiting for someone else to deal with it", which won't make them very happy.

12 hour stale data sounds kind of long to me. 4 hours sounds more reasonable.

Re: App Engine down

#80

Earlier quoted context omitted.

Which is better? Having a day of downtime each year, or not launching at all?

Which is better? Using a fallacious comparison to suggest cloud computing is the only viable option, or comparing the pros and cons of different computing models to choose the best one for you?

While the argument was perhaps coming on a bit too strong, it's hard to deny the ease of deployment on cloud services. It's probably a safe bet to say that for most early stage startups the cloud is a good move.
Post reply on HN