That's the kind of facile statement that makes people riotously mock the entire startup community, like "MongoDB is webscale" but even less valid.
Cloud services are not a panacea, and there are myriad situations in which running one's own infrastructure can be a good idea. What matters is that the issues and benefits are taken into account; if one can show research demonstrating that a custom infrastructure is cheaper, or more reliable, or less prone to legal issues, for example, then there's nothing to laugh at.
And remember that PaaS in particular can cost a buttload of money - I'm certain it's contributed to the downfall of more than one otherwise promising startup.
The advantage of cloud servers is if one experiences corruption or goes down you just kill it and start a new one. If your cloudy EBS equivalent experiences corruption, you restore from snapshot and off you go again. Either way it involves less downtime than HN seems to have. The downside is it costs more (usually, depends on how high your server management and data center overheads are.) I'd like to point out that despite several high profile down time incidents in the aws, never was there a case that I'm aware of where you couldn't just restore from your last snapshot to another availability zone or region.
You realize cloud services are vulnerable to data loss as well?[1] The cloud isn't some magic machine off in a datacenter somewhere. Its a bunch of servers and SANs just like what you or I would roll out if we needed bare metal infrastructure. The only difference is the extraordinary markup that you're paying amazon to use their servers.
Yes, obviously. That's why I said you should restore from backups in that event. If you lose your backups on S3, congratulations, you had better odds of winning in your state lottery. The big difference is not just the price as you say, but the flexibility.
And how do you guarantee the validity of your snap shot? has your process been writing corrupt records for the last n hours and not notice?
Do you even have access to that snapshot if the system is down?
the cloud simply exchanges know levels of failure with unknown level of failure. You pay someone else to think about it for you.
If there is a massive data loss at amazon, and people have been backing up to glacier, the recovery times will jump from hours to days even weeks, simply because there aren't enough drives to recover from.
The cloud may be more reliable, but when it goes down, it'll gown down hard, leaving you high and dry if you don't have real backups.
The same with any other incremental backup. You have a backup retention policy and go back to the last good one. Being in the cloud doesn't change that.
Yeah you can do private cloud as well. Docker lets you do that. It can cost a bit of money in the effort spent but payoff in the long run usually worth it - at scale.
HN is about hosting a forum for intelligent people to communicate various intellectual topics, not about being a dev/ops challenge. There is no good reason that they can't run this on some services/hardware that are more stable than what they've got. People behind the YC community (VCs investing in the HN companies and many of the successful founders) are millionaires+ so the "price" argument really dons't make sense. YC should be setting the example of how to do it right.
That's the kind of facile statement that makes people riotously mock the entire startup community, like "MongoDB is webscale" but even less valid.
Cloud services are not a panacea, and there are myriad situations in which running one's own infrastructure can be a good idea. What matters is that the issues and benefits are taken into account; if one can show research demonstrating that a custom infrastructure is cheaper, or more reliable, or less prone to legal issues, for example, then there's nothing to laugh at.
And remember that PaaS in particular can cost a buttload of money - I'm certain it's contributed to the downfall of more than one otherwise promising startup.