Hacker News Reader

Comment by jacquesm | Hacker News Reader

this is a bit like flying vs driving. If you're in the drivers seat you have control - you hope - and your destiny is in your own hands, if you're in a plane it is someone else driving (unless you are an airline pilot). The accident rate is lower for planes per mile flown but if it goes wrong then it usually does so in ways that make the headlines. Still, more people die driving than flying.

When the 'cloud' goes down (or at least some part of it) then you'll notice this immediately because of the large number of sites going down all at once. But when you compare it with the accumulated downtime of all those users had they not been 'cloud users' but hosted on their own kit then it is very well possible that the balance is still in favour of hosting in the cloud.

View on HN

Nice analogy but like all analogies, it's too simplistic and flawed. You left out one important and critical part: the hypothetical passenger in your example is tied to a specific plane/airline. If you don't like your pilot or plane type, you cannot move to a different airline or request a different plane or a different pilot since you're chained to the specific plane.

Due to Google App Engine's API lock-in, you're stuck with them as a provider... quite possibly forever due to heavy BigTable dependency.

Even though I'm a huge fan of cloud computing, I'd rather use a strategy that uses platforms/planes that are built from reusable parts and allow you to switch your plane/airline provider as you please. Don't like Delta? Just go to AA counter and you don't have to change your luggage, clothing etc.

Until there's a second, GAE-compatible, ISV provider that offers full compatibility with GAE, I'd avoid GAE like a plague.

I'm sorry sir, but if my pilot is stuck in a thunderstorm and I don't think he knows what he's doing, I can't "request a different plane."

Yes but if you survive the flight you can switch after you land.

or at least carry a parachute. business continuity plans should really be part of the spec for everyone who's making money from their app.

It's a metaphor, not a description or some sort of iron law of physics. If I was on Google App Engine right now and there was a competitor that I could switch too, then I damn well could be up, especially if I took the opportunity to keep both options actively available for myself. No matter how hard "switching planes in midair" might be, it's just a metaphor.

Does that account for 6 hours of downtime with minimal information as to what's going on? Good luck with that!

That's not a fair comparison. You can't switch mid flight or mid cloud crash. But you can evaluate safety records every time you feel inclined and swap your airlines at some point.

If GAE fails to live up to the better-then-DIY-on-average promise, you can't leave.

all understanding of the real world is simplistic and flawed. Even your analogy because there is no good cloud as service provided that offers anything as good as big table for distributed storage plus map reduce.

Actually, if this thing works then there is no longer an API lock-in with Google App Engine: http://code.google.com/p/appscale/

Assuming you can still dump your data out of Googlage?

Actually, as django abstracts the GAE-api, there's still a way to escape.

I think a better analogy for cloud computing is electricity. For mission critical applications investing the time and effort into a power / app backup is probably a good idea, but the onus is on us.

Great analogy. I would rather have all the big Brains at Google working to solve the problem instead of my puny brain working trying to restart my server

More specifically:

We have no real network administrators. Within our engineering team we collectively have the skill to be an effective at systems administration, but the hardware side is really a complete mystery.

Co-location mostly solves that, but the cloud takes it a step further. By running in a virtualized environment we can handle what we're good at it and let others build complex data centers to scale our traffic.

When your bootstrapping a start-up, that's just huge.

exactly, shit happens, if you host on your own, you are just as vulnerable to power outages etc. + at least when a cloud goes down, they have hundreds of pros trying to fix it

hope not. too many cooks?

I do my own hosting, but I agree with this completely. Downtime at any scale is inevitable, but with Google's massive infrastructure you're far better off.

A lot of sites get 99.99% uptime easily. It's not difficult when you know what you're doing and have plenty redundancy. When you depend on any cloud stuff you can't do any kind of graceful degradation. Google goes down, you go down. Google goes bankrupt, you go bankrupt.

Considering how cheap dedicated servers are moving a service to the cloud makes little sense (exceptions notwithstanding).

The hardware may be inexpensive, but "knowing what you're doing" and being able to pull 5 nines is definitely not cheap.

5 nines is not something you get on paper worth the ink normally. SLAs in the civil sector generally top out at 3 nines. Very, very rarely you talk about 4 and those are dealt out by the insurance company, not by the service provider.

I'm talking about real SLAs with compensation here, mind you, not the toilet paper you get from every cheapo ISP.

99.99% is only 52 minutes of downtime a year... I don't think any of S3, Rackspace, Goole AppEngine, or even www.amazon.com have uptime that good this year.

Getting that kind of uptime is much harder than it sounds and for a lot of websites not worth the extra cost. How much money would pay to go from 99.9% uptime (~9 hours /year) to 99.99% (52 minutes)?

I disagree. For a small to medium size site, getting 99.99% uptime should basically be the default. If you have a competent staff and a decent provider, about the only thing that will take you down is a power/equipment failure at the DC - which does happen, from time to time, admittedly. Yeah, Rackspace had some problems this year, but most of the other tier 1 hosts have been rock solid.

Obviously it's more complex for a large site but for the vast majority I would say that level of uptime is the rule rather than the exception.

Three nines is pretty unacceptable in this day and age. Providers might only guarantee that level of uptime but if they really were down that much I'd run a mile. Netcraft is your friend!

update: edited post to better reflect reality

How are you defining a site and uptime? Are you talking about dynamically switching systems to allow for upgrades without downtime?

I'm mostly wondering how it compares with the setup at my current location.

I have worked on systems that were designed for this, but I'm not sure if it's cost effective for most web applications. Most things can wait on occasion.

Thank you.

and what happens when an engineering fluke hits your KV store and locks it up. And it takes you 10hours to fix :)

You see your not actually paying for the 3 9's or the 5 9's. That is just corporate bullshit. Your paying for the promise that whatever the problem someone will be able to fix it in a few hours at most.

The cloud is just an enormous SPOF. I like having my own kit somewhere in the loop if only to throw a proper error message.

Reply on news.ycombinator.com