>> They don't care if you lose customers, as long as you don't cancel YOUR account.

Untrue (though I suppose it's possible they don't give a flying fuck, and you can ignore the rest of this post), their success is based on the success of their client(s). The same is applicable to all sorts of vendors providing services. It is in their best interest that every one of their clients is successful, in the same way it is of interest to your datacenter facilities that you continue to grow.

>> They'll get more new customers tomorrow due to the bad press, simply because those customers were out of the loop and just now heard about Heroku or AWS and it looks cool when they get there.

Certainly valid, and that is one of the benefits of having many clients vs. a few "big" clients. That doesn't reflect bad on heroku, aws, etc: it's just the nature of the industry they're in. The same applies to your datacenter renting out 1Us at a time instead of whole racks.

re: more clientele tomorrow -- plausible, possible, sure! The same applies to datacenter facilities that go offline.

>> Running your own servers is the responsible thing to do if you want to OWN your business and not just look cool by using the latest brand named cloud service thrown around by everyone.

There are benefits and drawbacks to {running,renting,owning} your own hardware in the same way there are drawbacks to using "cloud" providers (IaaS/PaaS). Let's not ignore those.

What is applicable to both scenarios however: build redundancy into whatever is important to you. Something, somewhere will fail & you'll be brought offline otherwise.

>> No, Heroku/AWS zealots will not agree with me, but they've never run their own data center. They have no experience.

I'm not a heroku / aws zealot, I run a competing hosting provider and I think they have their place in the market -- otherwise they wouldn't exist.

>> Get real people. The cloud is just a REALLY expensive way to sell shared servers.

It's fairly inexpensive to be honest -- it's cheap compared to having a team of sysadmins floating around touching things all day long. Quite frankly it isn't all that expensive in light of the fact that $client doesn't have to concern himself with hardware all day long.

>> I run my own servers on 3 dedicated 1gbps connections, and while you pay $0.12/GB on AWS/Heroku (actually, Heroku costs more, but they bury it in their worker pricing so it looks free), I pay $0.01 per GB. That's right, 1 cent per GB.

Kudos, you also worry about hardware all of the time -- I've got ~2-3 racks and I spend my days worrying about replacement gear, physical security, network topology & all kinds of other things that one running an app. probably doesn't want to concern themselves with. I mitigate this on behalf of my clients, and they send me money for space & bandwidth in return for them not having to worry about it all day.

Heroku & aws do this, too as do many other vendors.

>> While an 8-core machine costs me $0.42/hour all tolled (machine, power, space), you pay almost $0.66/hour on EC2 with no SLA, meaning you're not ALWAYS getting the same machine specs every minute of every hour. You're getting a MAXIMUM commitment of resources, not a MINIMUM commitment.

Colo. is definitely cheaper, at face value, but quite frankly most of the people on HN are concentrating on building applications. Their mental bandwidth needs to be spent on those applications, not hosting (though, obviously hosting is still part of the equation). Those people who are offline right now would be offline in the same scenario if their dc went offline due to power-outage/$random-reasons-things-go-offline.

Why? Because the people offline right now didn't build redundancy into their applications, and they wouldn't have if they had dedicated servers or an entire rack, either.

>> Heroku has been down 3+ hours this time, and last year had a 70+ hour outage. On my own servers, I haven't had 3 TOTAL hours of downtime in 5 years.

Congrats. Inevitably, a UPS will overload, a switch will die & you'll eat some downtime too. It happens -- build redundancy into your application / service to ensure that thy facility is irrelevant when the time comes.

That applies to everyone.