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

41–50 of 330 posts

Re: Use One Big Server (2022)

#41

Post by andersmurphy »

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…

If you're running on a single machine then you'll get way more performance with something like sqlite (instead of postgres/MySQL) which also makes managing the database quite trivial.

Re: Use One Big Server (2022)

#42

Post by fragmede »

cpursley wrote: post #37
lewisjoe wrote: post #20

I helped bootstrap a company that made an enterprise automation engine. The team wanted to make the service available as SaaS for boosting sales. They could have got the job done by hosting the service in a vps with a multi-tenant database schema. Instead, they went about learning kubernetes and drillingg deep into "cloud-native" stack. Spent a year trying to setup the perfect devops pipeline. Not surprisingly the co…

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.

Re: Use One Big Server (2022)

#43

Post by garganzol »

And then boom, all your services are gone due to a pesky capacitor on the motherboard. Also good luck trying to change even one software component of that monolith without disrupting and jeopardizing the whole operation.

While it is a useful advice to some people in certain conditions, it should be taken with a grain of salt.

Re: Use One Big Server (2022)

#44

Post by fragmede »

DaSHacka wrote: post #40
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...

> Or, play with servers and K8s, burning your investors money, then move on to the next gig and repeat... I mean, of the two, the PaaS route certainly burns more money, the exception being the rare shop that is so incompetent they can't even get their own infrastructure configured correctly, like in GP's situation. There are guaranteed more shops that would be better off self-hosting and saving on their current massi…

> the PaaS route certainly burns more money,

Does it? Vercel is $20/month and Neon starts at $5/month. That obviously goes up as you scale up, but $25/month seems like a fairly cheap place to start to me.

(I don't work for Vercel or Neon, just a happy customer)

Re: Use One Big Server (2022)

#45

Post by sam_lowry_ »

marcosdumay wrote: post #32
decasia wrote: post #7

Regardless of the cost and capacity analysis, it's just hard to fight the industry trends. The benefits of "just don't think about hardware" are real. I think there is a school of thought that capex should be avoided at all costs (and server hardware is expensive up front). And above all, if an AWS region goes down, it doesn't seem like your org's fault, but if your bespoke private hosting arrangement goes down, then…

> 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.

Re: Use One Big Server (2022)

#46

Post by andersmurphy »

turtlebits wrote: post #24

The problem is sizing and consistency. When you're small, it's not cost effective to overprovision 2-3 big servers (for HA). And when you need to move fast (or things break), you can't wait a day for a dedicated server to come up, or worse, have your provider run out of capacity (or have to pick a different specced server) IME, having to go multi cloud/provider is a way worse problem to have.

Most industries are not bursty. Overprovision in not expensive for most businesses. You can handle 30000+ updates a second on a 15$ VPS.

A multi node system tends to be less reliable and more failure points than a single box system. Failures rarely happen in isolation.

You can do zero downtime deployment with a single machine if you need to.

Re: Use One Big Server (2022)

#47

Post by fragmede »

garganzol wrote: post #43

And then boom, all your services are gone due to a pesky capacitor on the motherboard. Also good luck trying to change even one software component of that monolith without disrupting and jeopardizing the whole operation. While it is a useful advice to some people in certain conditions, it should be taken with a grain of salt.

That capacitor thing hasn't been true since the 90's.

Re: Use One Big Server (2022)

#48

Post by dang »

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.

Re: Use One Big Server (2022)

#49

Post by ocdtrekkie »

talles wrote: post #18
ocdtrekkie wrote: post #14

Earlier quoted context omitted.

My single on-premise Exchange server is drastically more reliable than Microsoft's massive globally resilient whatever Exchange Online, and it costs me a couple hours of work on occasion. I probably have half their downtime, and most of mine is scheduled when nobody needs the server anyhow. I'm not a better engineer, I just have drastically fewer failure modes.

Do you develop and manage the server alone? It's a quite a different reality when you have a big team.

Mostly myself but I am able to grab a few additional resources when needed. (Server migration is still, in fact, not fun!)

Re: Use One Big Server (2022)

#50

Post by randomtoast »

Those servers are mainly designed for enterprise use cases. For hobby projects, I can understand why someone would choose Hetzner over AWS.

For enterprise environments, however, there is much more to consider. One of the biggest costs you face is your operations team. If you go with Hetzner, you essentially have to rebuild a wide range of infrastructure components yourself (WAF, globally distributed CDN, EFS, RDS, EKS, Transit Gateways, Direct Connect and more).

Of course, you can create your own solutions for all of these. At my company, a mid-size enterprise, we once tried to do exactly that.

WAF: https://github.com/TecharoHQ/anubis

CDN: Hetzner Nodes with Cache in Finnland, USA and GER

RDS: Self-hosted MySQL from Bitnami

EFS: https://github.com/rook/rook

EKS: https://github.com/vitobotta/hetzner-k3s

and 20+ more moving targets of infra software stack and support systems

The result was hiring more than 10 freelancers in addition to 5 of our DevOps engineers to build it all and handling the complexity of such a setup and the keep everything up-to-date, spending hundreds of thousands of dollars. Meanwhile, our AWS team, consisting of only three people working with Terraform, proved far more cost-effective. Not in terms of dollars per CPU core, but in terms of average per project spending dollars once staff costs and everything were included.

I think many of the HN posts that say things like "I saved 90% of my infra bill by moving from AWS to a single Hetzner server" are a bit misleading.

Post reply on HN