Most active commenters
  • themafia(4)
  • icedchai(3)

←back to thread

Use One Big Server (2022)

(specbranch.com)
343 points antov825 | 18 comments | 31 Aug 25 17:29 UTC | HN request time: 0.227s | source | bottom
Show context
runako ◴[31 Aug 25 18:54 UTC] 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 #
1. themafia ◴[31 Aug 25 21:46 UTC] No.45087388[source]▶
On AWS if you want raw computational capacity you use Lambda and not EC2. EC2 is for legacy type workloads and doesn't have nearly the same scaling power and speed that Lambda does.

I have several workloads that just invoke Lambda in parallel. Now I effectively have a 1000 core machine and can blast through large workloads without even thinking about it. I have no VM to maintain or OS image to consider or worry about.

Which highlights the other difference that you failed to mention. Hertzner charges a "one time setup" fee to create that VM. That puts a lot of back pressure on infrastructure decisions and removes any scalability you could otherwise enjoy in the cloud.

If you want to just rent a server then Hertzner is great. If you actually want to run "in the cloud" then Hertzner is a non-starter.

replies(5): >>45087482 #>>45087535 #>>45087934 #>>45089944 #>>45090699 #
2. matt-p ◴[31 Aug 25 21:59 UTC] No.45087482[source]▶
Very few providers charge setup, some will provision a server within a 90s of an api call.
replies(1): >>45088242 #
3. solid_fuel ◴[31 Aug 25 22:05 UTC] No.45087535[source]▶
Strong disagree here. Lambda is significantly more expensive per vCPU hour and introduces tight restrictions on your workflow and architecture, one of the most significant being maximum runtime duration.

Lambda is a decent choice when you need fast, spiky scaling for a lot simple self-contained tasks. It is a bad choice for heavy tasks like transcoding long videos, training a model, data analysis, and other compute-heavy tasks.

replies(1): >>45088276 #
4. icedchai ◴[31 Aug 25 23:14 UTC] No.45087934[source]▶
That's fine, except for all of Lambda's weird limitations: request and response sizes, deployment .zip sizes, max execution time, etc. For anything complicated you'll eventually you run into all this stuff. Plus you'll be locked into AWS.
replies(1): >>45088263 #
5. themafia ◴[01 Sep 25 00:06 UTC] No.45088242[source]▶
Hertzner does on the server the OP was referencing:

https://www.hetzner.com/dedicated-rootserver/ax162-s/

replies(3): >>45088435 #>>45091335 #>>45091763 #
6. themafia ◴[01 Sep 25 00:10 UTC] No.45088263[source]▶
> request and response sizes

If either of these exceed the limitations of the call, which is 6MB or 256kB depending on call type, then you can just use S3. For large distributed task coordination you're going to be doing this anyways.

> deployment .zip sizes

Overlays exist and are powerful.

> max execution time

If your workload depends on long uninterrupted runs of time on single CPUs then you have other problems.

> Plus you'll be locked into AWS.

In the world of serverless your interface to the endpoints and semantics of Lambda are minimal and easily changed.

replies(1): >>45092486 #
7. themafia ◴[01 Sep 25 00:13 UTC] No.45088276[source]▶
> significantly more expensive per vCPU hour

It's almost exactly the same price as EC2. What you don't get to control is the mix of vCPU and RAM. Lambda ties those two together. For equivalent EC2 instances the cost difference is astronomically small, on the order of pennies per month.

> like transcoding long videos, [...] data analysis, and other compute-heavy tasks

If you aren't breaking these up into multiple smaller independent segments then I would suggest that you're doing this wrong in the first place.

> training a model

You're going to want more than what a basic EC2 instance affords you in this case. The scaling factors and velocity are far less of a factor.

replies(3): >>45090283 #>>45090675 #>>45094267 #
8. matt-p ◴[01 Sep 25 00:53 UTC] No.45088435{3}[source]▶
I don't think that negates the point I was making. Most don't, for example none of the providers on https://www.serversearcher.com/ seem to charge setup.
9. twotwotwo ◴[01 Sep 25 06:15 UTC] No.45089944[source]▶
> [Hetzner] charges a "one time setup" fee to create that VM. That puts a lot of back pressure on infrastructure decisions and removes any scalability you could otherwise enjoy in the cloud.

Hetzner Cloud, then! In the US, $0.53/hr / $333.59/mo for 48 vCPU/192GB RAM/960GB NVMe. Includes 8 TB/mo traffic, when 8 TB egress would cost $720 on EC2; more traffic is $1.20/TB when the first tier of AWS egress is $90/TB. No setup fee. Not that it's EC2 but there's clearly flexibility there.

More generally, if you want AWS, you want AWS; if you want servers you have options.

10. eska ◴[01 Sep 25 07:13 UTC] No.45090283{3}[source]▶
> If you aren't breaking these up into multiple smaller independent segments then I would suggest that you're doing this wrong in the first place.

Care to elaborate?

replies(1): >>45092713 #
11. jalk ◴[01 Sep 25 08:17 UTC] No.45090675{3}[source]▶
This article (from Nov. 2022) shows that "utilizing Lambda is preferable until Lambda is utilized about 40 to 50 % of the time"

https://medium.com/life-at-apollo-division/compare-the-cost-...

12. lachiflippi ◴[01 Sep 25 08:22 UTC] No.45090699[source]▶
Hetzner does not charge any provisioning fees for VMs and never has.
13. Aeolun ◴[01 Sep 25 10:16 UTC] No.45091335{3}[source]▶
If you are scared off by the €80 setup on a server that costs €200 a month, it seems like the setup fee did its intended job no?
14. ferngodfather ◴[01 Sep 25 11:20 UTC] No.45091763{3}[source]▶
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.
replies(1): >>45092224 #
15. benjiro ◴[01 Sep 25 12:32 UTC] No.45092224{4}[source]▶
> I don't believe they do the same for VPS / Cloud servers.

Because its backed into the price. If you run a VPS for a month, you get the listed monthly price. But if you run a VPS for a shorter time, the hourly billing price is a lot more expensive.

The ironic part being, that your better off keeping a VPS active until the end of your month periode (if you already crossed 2/3), then its is to cancel early.

Noticed that few people realize that the hourly price != the monthly price.

16. icedchai ◴[01 Sep 25 13:17 UTC] No.45092486{3}[source]▶
Of course, we can generally work around all these things. The point is it is annoying to do so. It adds friction and further couples you to a proprietary platform.

You're better off using ECS / Fargate for application logic.

17. icedchai ◴[01 Sep 25 13:57 UTC] No.45092713{4}[source]▶
You are expected to work around Lambda limitations because it's the "right way", not because the limitations make things overly complex. /s
18. runako ◴[01 Sep 25 16:41 UTC] No.45094267{3}[source]▶
This is a great example of what I meant when I said that a part of the Cloud Tax is it constrains the solution space available to developers. In an era where one can purchase, off-the-shelf, a 256-core machine with terabytes of RAM, developers are still counting megabytes(!) of file sizes due to the constraints of AWS.

It should be obvious that this is not the best answer for all projects.