Hacker News Reader

Comment by Scramblejams | Hacker News Reader

That comparison isn't apples to apples, though. Internal solutions are frequently less complex than cloud systems, and have fewer and more understandable failure modes as a result. I could throw a rock at my last job and hit mail servers that had better uptime than Gmail, to use one prosaic example.

View on HN

I literally can't remember the last time Gmail had an outage, and I've been using it for 8 years.

Good! You've been lucky. A few examples from the last 8 years:

http://www.pcworld.com/article/160153/google.html

http://news.softpedia.com/news/Longest-Gmail-Meltdown-in-His...

http://arstechnica.com/information-technology/2012/12/why-gm...

http://www.computerworld.com/article/2486914/web-apps/update...

Keep in mind, when comparing it to your experience, is that not all customers are necessarily down when there's a problem.

I'm not dumping on Gmail, running a giant system like that has got to be extremely challenging to get right.

But let's not wear rose-tinted glasses about the cloud. It can be great, but for some applications you can get better reliability by competent people deploying reliable software on reliable hardware.

> But let's not wear rose-tinted glasses about the cloud. It can be great, but for some applications you can get better reliability by competent people deploying reliable software on reliable hardware.

This doesn't jive with the tech industry hype train though, hence, it being "myopic" to consider running your own services internally.

Of course it's possible to achieve better uptime yourself. The question is not: is it theoretically possible to be more available than gmail. The question is is it cost-effective to do so, once all the relevant factors are considered.

Wow!!

Is there a list of outages on other 'major' services of this magnitude?

You may not, but if you run a server your customers will remember like an elephant.

http://m.huffpost.com/us/news/gmail-down

I've also seen internal systems become far more complicated because there was no check on what a project owner could request and cloud systems drive simplicity because e.g. you couldn't try to force Amazon to implement some weird custom behaviour one of your legacy app development teams thought they needed.

The general trend I follow is that you're good at things you do regularly. That means that internal systems tend to be much worse at recovering from failure (i.e. the time to recover can be days or even weeks) unless they are careful to design with redundancy in mind and practice it regularly. That's a time-honored tradition in large IT shops but it's also one which often requires constant effort to justify the "wasteful" expense even in places which should know better.

For many companies, especially smaller ones, the cost of setting up and managing infrastructure that can support high uptimes just isn't manageable. It's not just the hardware, it's also the price of hiring or contracting people with the expertise to do it.

Case in point: It's informative that you refer to "mail servers". The plural makes it clear that the company in question isn't in the same league, size-wise, as the target market for most SaaS vendors.

Depends. If you're hoping for high uptimes but aren't forced to guarantee them, you can get awfully far with a good Lenovo box running RAID1, Qmail and judicious application of uninterruptible power supplies.

If you're just after high uptimes for your email server, and your email server doesn't need to be anything more than an email server, and you already happen to have a need for a Unix server and a qualified Unix admin, then sure.

Typical companies, though, are mostly Windows shops and really are looking to get something more along the lines of an integrated communication/collaboration/scheduling tool like Microsoft Exchange or GMail.

I have to agree with this. We recently replaced a homegrown webapp with its MS Dyanmics GP equivalent and headaches have increased exponentially. It's as if the system was designed to be so complex as to require a team of people to operate, plus a manager to supervise, plus a support person to field phone calls... when one guy churned out the original in a day, and ran for a year-and-a-half with only minor technical (and no major organizational) hiccups.

When you write of Microsoft Dynamics GP, this FizzBuzz Enterprise Edition repo comes to mind: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

> It's as if the system was designed to be so complex as to require a team of people to operate, plus a manager to supervise, plus a support person to field phone calls

This is exactly it. Even if not intentionally designed, it ends up that way. As andrewstuart2 mentioned above, "[customers] also got the full expertise of the salesforce engineering organization (which clearly is far from incompetent) being brought to bear on the problem, at no extra charge to them as a customer". This is great I guess, but if your home-grown solution doesn't use, say, Oracle, to start out with, you're going to eliminate a heck of a lot of necessary engineering expertise when things go wrong. Break up systems even more and suddenly just one generalist can do it all on the side...

A classic build vs. buy situation where the purchase seems like the solution and in reality, it is a purchase plus development plus support. In many cases the internally designed, function specific, application is better because of its constrained functionality. Many companies, mine included, have made the mistake of purchasing a silver bullet rather than forging one with our own time, talent, and treasure.

Ya that's a fair point. I still think that in general you're likely to have worse uptime, or at best just comparable uptime to large cloud services in most cases.

Cloud services just have to be equal to internally run ones in this regard, since they save so much in other areas. So I guess people have to decide: is 20 hours of downtime every few years worth running your own services internally and paying people full time to manage them?

Reply on news.ycombinator.com