←back to thread

Use One Big Server (2022)

(specbranch.com)
343 points antov825 | 1 comments | | HN request time: 0s | source
Show context
runako ◴[] No.45085915[source]
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 overstate how far apart these machines are in raw computational capacity.

There are approaches to problems that make sense with 10x the capacity that don't make sense on the much smaller node. Critically, those approaches can sometimes save engineering time that would otherwise go into building a more complex system to manage around artificial constraints.

Yes, there are other factors like durability etc. that need to be designed for. But going the other way, dedicated boxes can deliver more consistent performance without worries of noisy neighbors.

replies(11): >>45086252 #>>45086272 #>>45086760 #>>45087388 #>>45088476 #>>45089414 #>>45091154 #>>45091413 #>>45092146 #>>45092305 #>>45095302 #
Spooky23 ◴[] No.45089414[source]
It really depends on what you are doing. But when you factor the network features, the ability to scale the solution, etc you get alot of stuff inside that $200/mo EC2 device. The product is more than the VM.

That said, with a defined workload without a ton of variation or segmentation needs there are lots of ways to deliver a cheaper solution.

replies(1): >>45089477 #
troupo ◴[] No.45089477[source]
> you get alot of stuff inside that $200/mo EC2 device. The product is more than the VM.

What are you getting, and do you need it?

replies(1): >>45089746 #
throwaway7783 ◴[] No.45089746[source]
Probably not for $200/mo EC2, but AWS/GCP in general

* Centralized logging, log search, log based alerting

* Secrets manager

* Managed kubernetes

* Object store

* Managed load balancers

* Database HA

* Cache solutions

... Can I run all these by myself? Sure. But I'm not in this business. I just want to write software and run that.

And yes, I have needed most of this from day 1 for my startup.

For a personal toy project, or when you reach a certain scale, it may makes sense to go the other way. U

replies(4): >>45090159 #>>45090268 #>>45090516 #>>45094149 #
eska ◴[] No.45090268[source]
Now imagine your solution is not on a distributed system and go through that list. Centralized logging? There is nothing to centralized. Secrets management? There are no secrets to be constantly distributed to various machines on a network. Load balancing? In practice most people for most work don’t use it because of actually outgrowing hardware, but because they have to provision to shared hardware without exclusivity. Caching? Distributed systems create latency that doesn’t need to exist at all, reliability issues that have to be avoided, thundering herd issues that you would otherwise not have, etc.

So while there are areas where you need to introduce distributed systems, this repeated disparaging comment of “toy hobby projects” makes me distrust your judgement heavily. I have replaced many such installations by actually delivering (grand distributed designs often don’t fully deliver), reducing costs, dramatically improving performance, and most importantly reducing complexity by magnitudes.

replies(4): >>45090918 #>>45092682 #>>45092931 #>>45103475 #
1. viraptor ◴[] No.45092682[source]
> Centralized logging? There is nothing to centralized.

It's still useful to have the various services, background jobs, system events, etc. in one indexed place which can also manage retention and alerting. And ideally in a place reachable even if the main service goes down. I've got centralised logging on a small homelab server with a few services on it and it's worth the effort.

> Load balancing? In practice most people for most work don’t use it because of actually outgrowing hardware, but because they have to provision to shared hardware without exclusivity.

Depending on how much you lose in case of downtime, you may want at least 2x of hardware for redundancy and that means some kind of fancy routing (whether it's LB, shared IP, or something else)

> Secrets management? There are no secrets to be constantly distributed to various machines on a network.

Typically businesses grow to more than one service. For example I've got a slack webhook in 3 services in a small company and I want to update it in one place. (+ many other credentials)

> Caching? Distributed systems create latency that doesn’t need to exist at all

This doesn't solve the need for caching results of larger operations. It doesn't matter how much latency you have or not, you still don't want that rarely-changing 1sec long query to run on every request. Caching is rarely only about network latency.