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

191–200 of 330 posts

Re: Use One Big Server (2022)

#191

Post by Aeolun »

andersmurphy wrote: post #46
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.

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

Just like a lot of problems exists between keyboard and chair, a lot of problems exist between service A and service B.

The zero downtime deployment for my PHP site consisted of symlinking from one directory to another.

Re: Use One Big Server (2022)

#192

Post by Aeolun »

Puts wrote: post #11
talles wrote: post #3

Don't forget the cost of managing your one big server and the risk of having such single point of failure.

My experience after 20 years in the hosting industry is that customers in general have more downtime due to self-inflicted over-engineered replication, or split brain errors than actual hardware failures. One server is the simplest and most reliable setup, and if you have backup and automated provisioning you can just re-deploy your entire environment in less than the time it takes to debug a complex multi-server set…

In my experience, my personal services have gone down exactly zero times. Actually not entirely true, but every time they stopped working the servers had simply run out of disk space.

The number of production incidents on our corporate mishmash of lambda, ecs, rds, fargate, ec2, eks etc? It’s a good week when something doesn’t go wrong. Somehow the logging setup is better on the personal stuff too.

Re: Use One Big Server (2022)

#193

Post by ferngodfather »

3shv wrote: post #189
t_mahmood wrote: post #184

Earlier quoted context omitted.

I don't get why people are so hell-bent on going to AWS, for the most minor applications, without looking at simpler options! I am not even thousands km near the level of what you are doing, but my client was paying $100/m for an AWS server, SQS and S3 bucket, for a small PHP based web application that uses Amazon Seller API, Keepa API for the products he ships. Used MySQL for data storage. I implemented the whole th…

What are some cheaper and better hosting providers that you can recommend?

Hetzner! They do ask for ID though.

Re: Use One Big Server (2022)

#194

Post by kiney »

vidarh wrote: post #105
bspammer wrote: post #84

Earlier quoted context omitted.

A fair comparison would include the cost of the DBA who will be responsible for backups, updates, monitoring, security and access control. That’s what RDS is actually competing with.

I do consulting in this space, and we consistently make more money from people who insist on using cloud services, because their setups tend to need far more work.

same for me

Re: Use One Big Server (2022)

#195

Post by ferngodfather »

themafia wrote: post #102
matt-p wrote: post #90

Earlier quoted context omitted.

Very few providers charge setup, some will provision a server within a 90s of an api call.

Hertzner does on the server the OP was referencing: https://www.hetzner.com/dedicated-rootserver/ax162-s/

Most providers do for dedicated servers, or make you agree to a fixed term. I don't believe they do the same for VPS / Cloud servers.

Re: Use One Big Server (2022)

#196

Post by cpursley »

Aeolun wrote: post #186
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...

The moment I sign up for a PaaS the bill hurts. I can never get over the fact I can get 1000x more compute for the same price, never mind that I never use it and have to set everything up myself. I’ll just never pay to lock myself in to something so restricted. My dedicated server allows me to do anything I want or need.

If you enjoy playing with servers instead of shipping features, enjoy!

Re: Use One Big Server (2022)

#197

Post by christophilus »

applied_heat wrote: post #123
shrubble wrote: post #91

Earlier quoted context omitted.

Paying someone $2000 to set that up once should result in the costs being recovered in what, 18 months? If you’re running Postgres locally you can turn off the TCP/IP part; nothing more to audit there. SSH based copying of backups to a remote server is simple. If not accessible via network, you can stay on whatever version of Postgres you want. I’ve heard these arguments since AWS launched, and all that time I’ve bee…

$2k? That’s a $100k project for a medium size Corp

$200 does seem too low. $100k seems waaay too high. That sounds like an AWS talking point.

Re: Use One Big Server (2022)

#198

Post by cpursley »

Aeolun wrote: post #187
theaniketmaurya wrote: post #93

Earlier quoted context omitted.

I’m using Neon too and upgraded to the scale up version today. Curious, what do you mean rhat they can get pricey?

Like, you keep your server running for a month and you need to pay $255 pricey? I can get about 64 cores of dedicated compute for the price of a single neon compute (4c/16gb) unit. And that’s before you factor in 500gb of storage.

And how much time are you spending babysitting all of this? What’s your upgrade, deploy and rollback story? Because I don’t have to even think about these things.

Re: Use One Big Server (2022)

#199

Post by christophilus »

cedws wrote: post #174
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…

I don’t disagree but “cores” is not a good measure of computational power.

True, but the cores on a dedicated Hetzner box obliterate the cores on an EC2 machine every time I’ve tested them. So, if anything, it understates the massive performance gap.

Re: Use One Big Server (2022)

#200

Post by sevensor »

runako wrote: post #62
Demiurge wrote: post #53

Earlier quoted context omitted.

I think it’s the other way around. I’m a huge fan of Hetzner for small sites with a few users. However, for bigger projects, the cloud seems to offer a complete lack of constraints. For projects that can pay for my time, $200/m or $2000/m in hosting costs is a negligible difference. What’s the development cost difference between AWS CDK / Terraform + GitHub Actions vs. Docker / K8s / Ansible + any CI pipeline? I don’…

> I really don't see how "bare metal" saves any engineering time This is because you are looking only at provisioning/deployment. And you are right -- node size does not impact DevOps all that much. I am looking at the solution space available to the engineers who write the software that ultimately gets deployed on the nodes. And that solution space is different when the nodes have 10x the capability. Yes, cloud prov…

I’ve seen multiple projects founder on the complexity of writing software for the cloud. Moving data from here to there ends up being way harder than anybody expected. Maybe teams with more experience build this into their planning, but from what I’ve seen, if you’re using the cloud, your solution ends up being 95% about getting data where it’s supposed to be and 5% application logic.
Post reply on HN