Hacker News Reader

Comment by themafia | Hacker News Reader

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.

View on HN

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.

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

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

You are expected to work around Lambda limitations because it's the "right way", not because the limitations make things overly complex. /s

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

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.

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.

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

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.

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

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/

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.

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?

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.

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

Hetzner does not charge any provisioning fees for VMs and never has.

Reply on news.ycombinator.com