Comment by chx | Hacker News Reader

Comment by chx | Hacker News Reader

Parent Full thread

Kubernetes is only a threat in that it is a buzzword much as cloud is a buzzword. The cloud and Kubernetes both are used to sell a triple fallacy: You need to care about scaling from day one, there is an easy way to scale, this way is the cloud/Kubernetes.

For almost all startups their app would run comfortably on a single dedicated server. This has been true for many, many years but only the YAGNI greybeards would go with it. Maybe two HA but even HA is overhyped, it's cheaper to be down. Down is part of this industry, you will be down in many circumstances anyways so perhaps don't chase a unicorn? Of course, above a certain size, two servers make sense but ... don't overdo it even then. You don't need microservices, you don't need containers. All of this is unnecessary hype. (And yes, both of you who works at a large enough company where being down is enough of a problem that it worths engineering about: good for you. I have architected a Top 100 website myself and we still didn't use more than a dozen servers and that included the staging infra.)

Gary Bernhardt of WAT fame from 2015 https://twitter.com/garybernhardt/status/600783770925420546?...

> Consulting service: you bring your big data problems to me, I say "your data set fits in RAM", you pay me $10,000 for saving you $500,000.

Very strongly related: a terabyte of RAM in just 16 modules so it fits most server boards is now under $5000 https://memory.net/product/p00926-b21-hp-1x-64gb-ddr4-2933-l...

Final shot, codinghorror of StackOverflow fame: https://twitter.com/codinghorror/status/347070841059692545

Containers, k8s (or k3s, because less bloat) and micro-SOA (but preferably in a monorepo) make development easier.

Overdoing the infra-HA-magic is bad, of course. But if you use containers, you can spin up dev envs faster, devs can just docker-compose (I still recommend Vagrant + docker, so devs can use whatever OS they like), and it helps with config management a bit too. (Much easier testing, deployment and upgrades.)

That said paying for AWS is the worst idea ever, it's so overpriced and the most used servie is EC2, which people could get anywhere else. (Sure, there are probably nice tricks that this pony can do, but there's probably a whole cottage industry trying to copy their niche offerings.)

Cheaper to be down? I guess if you don’t have users sure.

Having a hot spare, a database slave and a mirror of your assets so you can manually fail over? Probably a good idea. Architecting a very HA infra? Now wait and look hard at all the possible downtime causes (you have a DDoS provider for sure, Voxility or Cloudflare probably, what if they go down and so forth) and so and then look at what you are protecting against: a hardware failure which is exceedingly rare and again you can manually failover. The costs vs benefits will not come out in your favor up to a very large company size where even the smallest amount of downtime is so costly it doesn't matter how many engineering hours go into avoiding it.

Anecdotal evidence.

I remember working for a company about a decade ago where we spent so much time engineering duplicate everything hardware or hot spares everywhere.

Guess what, when switch failed it didn't properly failed over. When router it started sending spurious packets everywhere and had to be taken down manually.

All the effort that went into duplicating hardware and making hot spares could have been save by just... having cold spares, and in the end the amount of downtime would have been the same, or less -- because when one thing fails it's really easy obvious where things stopped working.

Reply on news.ycombinator.com