| HN Mirror

This post is exactly the sort of thing I see a lot. It belies inexperience with systems when they go bad. And systems basically always go bad. (I made a very good living off of that!)

You know what you don't get with a Hetzner--which is fine for what it is, this is impugning their customers and not them as a provider? You don't get the for-free metrics and alerting of an AWS. You don't get their sizing. You don't get their effectively-infinite inventory (EDIT: I was just reminded of a former employer who managed to make AWS tap out of a particular instance type in a region--how do you think Hetzner's gonna fare if you hit that kind of scale? Are you sure you built an effectively multi-region, multi-master system on your magic k8s cluster?). You don't software-driven infrastructure at every layer of your stack--sure, you get kubectl, now scale your cluster without waiting for hours for a human to rack a machine. Also without crossing your fingers every time.

(Scaleway is better about APIs and responsiveness, to their credit. But we're not out of the woods yet you are now the barrier to reliability and you're going to have to invent or duct-tape half of a cloud provider on your own to get something done. I too enjoy not doing things that help ship products, but not when I need money...)

You know what you do get, though? You get risk. You're worse at data integrity and backup than AWS is and Hetzner is worse at DR options than AWS; these are not exactly controversial statements, so I trust that you'll just go with it. But wait, there's more--you also get inflexibility. You get the risk of k8s itself--which is, let's be real, kind of a tire fire if you aren't Google, I've never seen a k8s shop of nontrivial size where something wasn't constantly alerting or broken. And you also get inefficiency. You get inefficiency of spend as you buy more hardware than you need and then pay the marginal cost of managing and alerting all of it, because you need overhead space--which is usually deadweight space--for when your hardware fails. (Because your hardware will fail, and you need a way to fail over.) And you get inefficiency of people; you get to waste the time of an expensive resource (or apply an incompetent one, which might be your thing but it sure isn't mine) reinventing the wheel over and over again. Sure, you can run a RabbitMQ instead of a SQS. I hope you know how to deal with its nonsense (I barely do, and I've run it at scale) and I hope you have an ironclad backup plan for it. And even when you do, you get the people-time inefficiency of building and maintaining and spending time and attention on things you get as part of your "hardware" spend with a full-featured cloud provider.

From all indications from over a hundred clients at sizes from five employees to fifty thousand, you probably are no exception to any of the above. And maybe I'm wrong about that, maybe you're the one exception who does. But I will always bet the other way, even when it's me and I know that I'm no slouch at this, and that's why I use AWS or GCP. (It doesn't hurt that, ultimately, it ends up being cheaper, both because I need fewer infrastructure/devops people to manage it and because I build systems that don't require one to run enormous servers--when you don't box yourself into the corner of "I need to run this big fat daemon all day long" you can spend remarkably little on AWS or GCP in the first place!

Maybe doing things the hard, slow, scary, and risky way is your thing, and you're willing to pay in time, effort, and risk rather than in money. But, one, it really isn't much money if you're running something successful, and two, it is downright disingenuous to imply that the spend is like-for-like.