Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use One Big Server (2022)

specbranch.com

Post reply on HN
Print view View original

71–80 of 330 posts

Re: Use One Big Server (2022)

#71

Post by marcosdumay »

sam_lowry_ wrote: post #45
marcosdumay wrote: post #32

Earlier quoted context omitted.

> I think there is a school of thought that capex should be avoided at all costs (and server hardware is expensive up front). Yes, there is. Honestly, it looks to me that this school of thought is mostly adopted by people that can't do arithmetic or use a calculator. But it does absolutely exist. That said, no, servers are not nearly expensive enough to move the needle on a company nowadays. The room that often goes…

Connectivity is a problem, not the room. I ran the IT side of a media company once, and it all worked on a half-empty rack of hardware in a small closet... except for the servers that needed bandwidth. These were colocated. Until we realized that the hoster did not have enough bandwidth, at which point we migrated to two bare metal servers at Hetzner.

It's connectivity, reliable power, reliable cooling, and security.

The actual space isn't a big deal, but the entire environment has large fixed costs.

Re: Use One Big Server (2022)

#72

Post by matt-p »

railorsi wrote: post #63
matt-p wrote: post #6

A thoroughly good article. It's probably worth also considering adding a CDN if you take this approach at scale. You get to use their WAF and DNS failover. A big pain point that I personally don't love is that this non-cloud approach normally means running my own database. It's worth considering a provider who also provides cloud databases. If you go for an 'active/passive' setup, consider saving even more money by u…

What’s the issue with running Postgres inside a docker container + regular backups? Never had problem and relatively easy to manage.

no PITB, but mostly just 'it's hassle' for the application server I literally don't need backups, just automated provisioning/docker container etc. Adding postgres then means I need full backups including PITB because I don't even want to lose an hours data.

Re: Use One Big Server (2022)

#73

Post by api »

I’ve found that it’s hard to even hire engineers who aren’t all in on cloud and who even know how to build without it.

Even the ones who do know have been conditioned to tremble with fear at the thought of administrating things like a database or storage. These are people who can code cryptography kernels and network protocols and kernel modules, but the thought of running a K8S cluster or Postgres fills them with terror.

“But what if we have downtime!” That would be a good argument if the cloud didn’t have downtime, but it does. Most of our downtime in previous years has been the cloud, not us.

“What if we have to scale!” If we are big enough to outgrow a 256 core database with terabytes of SSD, we can afford to hire a full time DBA or two and have them babysit a cluster. It’ll still be cheaper.

“What if we lose data?” Ever heard of backups? Streaming backups? Hot spares? Multiple concurrent backup systems? None of this is complex.

“But admin is hard!” So is administrating cloud. I’ve seen the horror of Terraform and Helm and all that shit. Cloud doesn’t make admin easy, just different. It promised simplicity and did not deliver.

… and so on.

So we pay about 1000X what we should pay for hosting.

Every time I look at the numbers I curse myself for letting the camel get its nose under the tent.

If I had it to do over again I’d forbid use of big cloud from day one, no exceptions, no argument, use it and you’re fired. Put it in the articles of incorporation and bylaws.

Re: Use One Big Server (2022)

#74

Post by matt-p »

shrubble wrote: post #69
runako wrote: post #26

One of the more detrimental aspects of the Cloud Tax is that it constrains the types of solutions engineers even consider. Picking an arbitrary price point of $200/mo, you can get 4(!) vCPUs and 16GB of RAM at AWS. Architectures are different etc., but this is roughly a mid-spec dev laptop of 5 or so years ago. At Hetzner, you can rent a machine with 48 cores and 128GB of RAM for the same money. It's hard to overstat…

It's more than that - it's all the latency that you can remove from the equation with your bare-metal server. No network latency between nodes, less memory bandwidth latency/contention as there is in VMs, no caching architecture latency needed when you can just tell e.g. Postgres to use gigs of RAM and then let Linux's disk caching take care of the rest (and not need a separate caching architecture).

The difference between a fairly expensive ($300) RDS instance + EC2 in the same region vs a $90 dedicated server with a NVME drive and postgres in a container is absolutely insane.

Re: Use One Big Server (2022)

#75

Post by PaulKeeble »

I often wonder if my home NAS/Server would be better off put onto a rented box or a cloud server somewhere, especially since I now have 1gbit/s internet. Even now the 20TB of drive space and 6 Cores with 32GB on Hetzner with a dedicated is about twice the price of buying the hardware over a 5 year period. I suspect the hardware will actually last longer than that and its the same level of redundancy (RAID) on a rented dedicated so the backup is the same cost between the two.

Using cloud and box storage on Hetzner is more expensive than the dedicated server, 4x owning the hardware and paying the power bill. AWS and Azure are just nuts, >100x the price because they charge so much for storage even with hard drives. Contabo nor Netcup can do this, its too much storage for them.

Every time I look at this I come to the same basic conclusion, the overhead of renting someone else’s machine is quite high compared to the hardware and power cost and it would be a worse solution than having that performance on the local network for bandwidth and latency. The problem isn't so much the compute performance, that is relatively fairly priced, its the storage costs and data transfer that bites.

Not really what the article was necessarily about but cloud is sort of meant to be good for low end hardware but its actually kind of not, the storage costs are just too high even a Hetzner Storage box.

Re: Use One Big Server (2022)

#76

Post by matt-p »

fragmede wrote: post #42
cpursley wrote: post #37

Earlier quoted context omitted.

Yep, this is why I'm a proponent of paas until the bill actually hurts. Just pay the heroku/render/fly tax and focus on product market fit. Or, play with servers and K8s, burning your investors money, then move on to the next gig and repeat...

Yeah, same. Vercel + Neon and then if you actually have customers and actually end up paying them enough money that it becomes significant, then you can refactor and move platforms, but until you do, there are bigger fish to fry.

100%. Making it a docker container and deploying it is literally a few hours at most.

Re: Use One Big Server (2022)

#77

Post by matt-p »

api wrote: post #73

I’ve found that it’s hard to even hire engineers who aren’t all in on cloud and who even know how to build without it. Even the ones who do know have been conditioned to tremble with fear at the thought of administrating things like a database or storage. These are people who can code cryptography kernels and network protocols and kernel modules, but the thought of running a K8S cluster or Postgres fills them with te…

I have also found this happening. It's actually really funny because I think even I'm less inclined to run postgres myself these days, when I used to run literally hundreds of instances with not much more than PG_DUMP, cron and two read only replicas.

These days probably the best way of getting these 'cloudy' engineers on board is just to tell them its Kubernetes and run all of your servers as K3s.

Re: Use One Big Server (2022)

#78

Post by bpye »

dang wrote: post #48

HN uses two—one live and one backup, so we can fail over if there's a hardware issue or we need to upgrade something. It's a nice pattern. Just don't make them clones of each other, or they might go BLAM at the same time! https://news.ycombinator.com/item?id=32049205 https://news.ycombinator.com/item?id=32032235 https://news.ycombinator.com/item?id=32028511 ( --- Edit: both these points are mentioned in the OP.

Whilst not as fatal as a failing SSD, AMD also had a fun errata where a CPU core would hang in CC6 after ~1044 days.

https://www.servethehome.com/amd-epyc-7002-rome-cpus-hang-af...

Re: Use One Big Server (2022)

#79

Post by Havoc »

>Unfortunately, since all of your services run on servers (whether you like it or not), someone in that supply chain is charging you based on their peak load.

This seems fundamentally incorrect to me? If I need 100 units of peak compute during 8 hours of work hours, I get that from Big Cloud, and they have two other clients needing same in offset timezones then in theory the aggregate cost of that is 1/3rd of everyone buying their own peak needs.

Whether big cloud passes on that saving is another matter, but it's there.

i.e. big cloud throws enough small customers together so that they don't have "peak" per se just a pretty noisy average load that is in aggregate mostly stable

Re: Use One Big Server (2022)

#80

Post by bpye »

PaulKeeble wrote: post #75

I often wonder if my home NAS/Server would be better off put onto a rented box or a cloud server somewhere, especially since I now have 1gbit/s internet. Even now the 20TB of drive space and 6 Cores with 32GB on Hetzner with a dedicated is about twice the price of buying the hardware over a 5 year period. I suspect the hardware will actually last longer than that and its the same level of redundancy (RAID) on a rente…

I think I’ve settled on both being the answer - Hetzner is affordable enough that I can have a full backup of my NAS (using ZFS snapshots and incremental backups), and as a bonus can host some services there instead of at home. My home network still has much lower latency and so is preferable for ie. my Lightroom library.
Post reply on HN