Hacker News Reader

Comment by mlhpdx | Hacker News Reader

Not untrue, but also not true. It isn’t a Lambda problem, It’s the problem of running the same old, same old code on lambda.

Running clusters of VM/container/instances to “scale up” to transient demand but leaving largely idle (a very, very common outcome) then an event oriented rewrite is going to save a big hunk of money.

But yeah, if you keep every instance busy all the time, it is definitely cheaper than lambda busy all the time.

View on HN

Sure, if you’re willing to rewrite for an event-based architecture you can avoid the problem, but the post is a framework designed for running on Lambda without that rewrite. One of the stated goals is to have the same container run on EC2 or Fargate.

I understand the point. It’s one in a long line of such enabling tech — all leading to the same outcome.

A lot of internal web apps with low TPS can be easily ported to Lambda using these adapters. They should be the main use case IMO.

A lot of internal web apps with low TPS can easily be run on a $5-30/month vps.

The minimum cost of running a task on Fargate is under a dollar a month. If you’re a AWS company, you can get cheaper if you take the lock in (not that there’s much lock-in with Fargate)

> Running clusters of VM/container/instances to “scale up” to transient demand but leaving largely idle (a very, very common outcome) then an event oriented rewrite is going to save a big hunk of money.

If you're using k8s, HPA is handled for you. You just need to define policies/parameters. You're saying as if rewriting an entire app doesn't cost money.

Reply on news.ycombinator.com