Slashdot Mirror
GMail Experiences Serious Outage
JacobSteelsmith was one of many readers to note an ongoing problem with Gmail: "As I type this, GMail is experiencing a major outage. The application status page says there is a problem with GMail affecting a majority of its users. It states a resolution is expected within the next 1.2 hours (no, not a typo on my part). However, email can still be accessed via POP or IMAP, but not, it appears, through an Android device such as the G1." It's also affecting corporate users: Reader David Lechnyr writes "We run a hosted Google Apps system and have been receiving 502 Server Error responses for the past hour. The unusual thing about this is that our Google phone support rep (which paid accounts get) indicated that this outage is also affecting Google employees as well, making it difficult to coordinate."
Seems to be fine at the moment. Is this the first anti-slashdot-effect?
The wheel is turning, but the hamster is dead.
So much for handing your email over to Google because it's more reliable than hosting locally...
To do list for Windows
I don't know that this is actually news-worthy. I have never worked for a company which has not suffered email outages, no matter how their email is supported. Granted, GMail has a large list of client companies, but you are a fool of the highest order if you think the name will protect you from outages.
Great job slashdotting my email, dammit.
To do list for Windows
The cloud is falling! The cloud is falling!!
Although my Thunderbird access to Google Apps works fine. :)
WTF how did you get access to my gmail account?
As I type this, I can get in to GMail just fine, but a friend in Texas can't (I'm in Nevada). Guess Google likes us better.
And kudos to the Google team for updating the status when they say they will. Looks like the script they use automatically puts current time + 1 hour in as the default next update time, and they're posting updates before that expire. Too many times, something simple like that gets overlooked.
Or someone will get congratulated and promoted. It depends on the response to diagnose and fix the issue, whatever it is. Major outages aren't always the fault of some apocryphal guy asleep at the switch.
I think Gmail is a great service for personal accounts...
but for business sorry you need to pay a real live person or support company who will actually be able to deal with your data
how do you get the data out of gmail to switch providers ?
ever serviced a discovery litigation from google ?
(you know where they judge you guilty of you dont come up with the data)
sorry but there is a good reason to keep this stuff on site and working...
regards
John Jones
It it's true that this outage is affecting Google too I have to say that is a good thing. Eating your own dog food, product-wise, is always a good idea.
.: Max Romantschuk
Upside: shows confidence in your products; makes it more likely that your engineers will spot problems if they use the software and services themselves; can increase how motivated people are to improve the products
Downside: tainted dogfood kills the engineers who would have investigated the issue
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Why would you fire the guy who caused it. He would probably be the most carful employee after that. People learn from mistakes firing people even for big mistakes isn't a solid business model and bad HR.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I drank the Google kool-aid about six months ago and moved my personal domain's mail over to the free gmail service. I've been extremely happy with it ever since.
I think it's interesting that I couldn't access my personal domain gmail during this outage, but my @gmail.com account worked without issue.
I use my gmail account whenever I sign up for free services. This is serious people! Where will all my spam go? Oh, wait, nevermind...
That'd be a good name for a superhero: Apocryphal Guy. You always hear about his exploits but never actually see them.
Lemme call up Marvel. I mean, Disney.
...following the principles of Heisenburger's Uncertain Cat...
I doubt it. Once you get out of high school and work in the real world, you'll find that just because something happens, people don't always get fired.
Why, because usually you'll be firing one of your best employee's a 20 percenter, one of the ones that actually does the work and knows what is going on. And even if it wasn't a 20 percenter , you don't want to send out the message, that if you do something and it causes a problem you're going to get fired.
I can hear it now, "Remember Bob, he was like us, then one day he went out and did something, something went wrong, so they shit canned him. That was five years ago and we haven't done anything since."
... while the assumption has always been "backups are not necessary with gmail" ...
I really want to know who started that stupid idea. You always want multiple off-site backups of anything important, cloud resources such as gmail and google docs count as one of those sources, you still want others. You also want local copies of any data that you absolutely have to have, what if your local ISP is having troubles and you need to access important documents?
There are a hundred things that could go wrong with using any off-site service as your one and only solution from simple outages and lost passwords to having all your eggs in one basket if someone hacks in or uses elevated privileges to do malicious deeds. The idea that any cloud based resource or offsite backup solution is the be-all, end-all solution for secure data storage is stupid and extremely lazy.
but you also have to pay google for the privilege of asking "so whats wrong?
Or, you could NOT pay Google at all, and when something goes wrong, realize that being able to call and ask what is going wrong is not going to get it fixed any sooner, and wait until they fix it.
Having someone soothe you over the phone during the process is a waste of money.
paintball
I'm sure there's slashdot readers for whom setting up (and maintaining) their own mail server is a short task done before breakfast without breaking a mental sweat.
Not really. The problem is that, as with most hard tasks, it's easy to trivialize in the abstract. In 10 seconds, I can type a command-line script that will answer port 25. In a slightly longer time I can pull down the appropriate packages for the Linux distro of choice and configure them with whatever domain name. In slightly longer, I can configure appropriate countermeasures and firewalling. Given budget and time, I can deploy a suite of additional features including redundancy (local and/or remote), various protocols for access to the mail, a Web front-end, calendaring, mailing list handling, archival, SOx-compliant retention management, monitoring, escalation paths, and so on...
Or I can sign up for Google Apps and have all of the above deployed in under a half hour for a company of nearly arbitrary size with customizations (logo, URLs for local support, internal documentation updates, etc.) being done within a week and larger-scale work (changing deployment manifests for new systems to ensure compatible browsers and pre-configured IMAP clients, etc.) being done over the course of the next month or two in conjunction with other parts of the organization.
After running my own mail servers for a decade, I finally gave in and went the Google route for my personal domain, and I'd recommend it for any size organization. There are pitfalls. You'll have to adapt or replace pieces of what Google gives you (their mailing list management is atrocious). But I feel that the work they leave in your lap is a very small trade-off given what you get.
...and as someone else wrote, we're now seeing the reason why.
Cloud computing is exactly the kind of buzzword-laden, idiotic fad that tends to be loved both by corporate marketing droids and technophobic Baby Boomers, both of whom have roughly equivalent levels of intelligence.
All it is going to take is a single major, successful DDoS attack against Google or some other cloud provider, and the cloud will go to the memetic rubbish bin where it belongs.
If you're one of the intellectual cripples who has difficulty understanding why cloud computing is a bad idea, ask yourself the question of whether or not you're going to be able to access your email if Google goes down, or if web access outside your ISP's own subnet does.
Yes, I have a Gmail account, but it is a convenience linked to my WoW blog, and a spam trap at best. It isn't something which I rely on for anything truly important, because I'm old enough to remember decentralised email, and to have more fucking sense.
Darn fool kids; they never learn. We keep seeing the same old mistakes being made, over and over and over again. I'm reminded of the old Frantics song, here.
Dumb terminal/"cloud" computing? Boot to the head. Creating a single, centralised point of failure which is just waiting for a DDoS attack. Genius.
XML/binary format RPC in GUIs? Boot to the head. Opaque, undiscoverable, uneditable, and totally unnecessary, except in the minds of marketing suits, or post-pubescent CS grads who've been fed corporate Kool-Aid. Use sockets, morons.
Binary subpackaging of libraries? Boot to the head. Given what bandwidth and disk space is at these days, any claim that it saves space is totally bogus, and the only thing it does do is add needless complexity, and reduce reliability. Put the whole thing in a single package, and stop thinking you're smart for doing otherwise. You're not.
Writing opaque package management in C, with a dep list a mile long, when a system written in shell, awk, and using the graph/dep management ability of Make itself would work probably more effectively? Boot to the head. Although sorry; I keep forgetting that Awk isn't considered a "real," programming language. You might want to let the guys using it for AI research know that, though; they could forget otherwise.
Being a snot nosed, latte sipping, yuppie CS graduate who thinks they know how to code, and then spawning attrocities like Dbus? Boot to the head. The kernel hardware notification system and udev work perfectly well by themselves. Adding more daemons when you don't need to simply adds unnecessary complexity, which again potentially reduces robustness.
Writing opaque, non-standard, dynamic GUI "automounter" garbage for Crapbuntu instead of teaching users how to edit /etc/fstab? Boot to the head. Use things which are easily locatable, and written in text which can likewise be edited easily. Then again, I guess I can't expect the Stallmanite 14 year olds who code Linux's userland these days to know about real UNIX philosophy, now can I?
Causing GRUB to default to "quiet splash," in Crapbuntu so that when the boot process inevitably fails due to the distro coming with Bit Torrent servers by default, the user can't see the daemon that is causing the boot process to fail, and are thus left with a totally opaque, unfixable black screen that they can't recover from? Boot to the fucking head, x100.
Plural second person future perfect:
all'ya'll'll've
Usage:
All'ya'll'll've been doin' it wrong if all'ya'll do what yer plannin' on doin'.
Most of the long distance in the country dropped that day, triggered by 4ESS switches hitting a bug, detecting, it, going offline (with load shifted to other switches). Increased load made the bug in question more likely to be hit, so those switches would in turn drop and shift load away (sometimes back to the originator). 9 hours of basically no long-distance service.
And just think, it was a year and a half before Berners-Lee announced the "World Wide Web" and Linus announced that he was working on this "Linux" thing.
fencepost
just a little off
That's why its still it beta... oh wait >_
This Gmail outage is provoking concerns over the reliability of cloud computing. However, there is nothing to be concerned about. Gmail actually has little to do with cloud computing. It is a hosted service. The appropriate paradigm for Gmail is black box.
Gmail is single point of failure. Your data is stored at one location. When that location is unavailable your data is inaccessible. An opaque, inscutable black box is the correct analogy.
If you were actually applying the principles of cloud computing to email then your data would be replicated among several black box vendors. The outage of a single vendor would not cut off your access.
In short, we dream of the promise of cloud computing but very few true cloud computing services have been implemented. The most conspicuous example of a working cloud computing service is IP packet routing and IMHO it works great.