Hacker News Reader

Comment by cogman10 | Hacker News Reader

This was my thought. Lambda works well for infrequent tasks. But hosting an API? That seems like it could get expensive pretty fast.

View on HN

It's cheaper than most options where you need to pay a human to manage something with the same level of scalability and security that AWS provides.

Lambda scalability for an API is awful; it can't run concurrent requests (of course PHP largely can't do this either). An ECS service with pretty much any other language (for async/multithreaded runtimes) will scale far better.

A single lambda can only handle one request at a time, but you can scale up 1,000s of instances if needed.

A single minimal ECS instance can handle thousands of concurrent requests with an async runtime without running into so many cold starts that your p25 time is in the hundreds of ms.

1000 lambdas with 1000 database connections is also going to be a horrible way to do things on the backend. Add in the cost of RDS proxy for lambda and the ECS solution becomes even better.

ECS fargate is pretty easy to scale, and much more cost effective.

I personally don’t think running on EC2 is particularly difficult to manage, and it’s even cheaper again.

Lambda is $0.0000166667 for every GB-second, which works out to ~$43.20 for 30 days. For a little more ($49/month), you could get a c6g.large and get two dedicated CPU cores (ie, not the shared burstable t2/t3) and 4 GB of RAM.

So yes, very expensive fast if you get much traffic at all. That c6g.large should easily be able to handle dozens (if not hundreds) of requests in parallel, especially if many of those requests are going to have to wait for results from a database.

If you have more than ~800 hours of Lambda execution time per month (30 days being 720 hours), then you're better off with the c6g.large. The only reason to choose the Lambda is if your traffic is extremely bursty and the c6g.large can't handle the load.

Of course, this is all assuming you're using a 1 GB Lambda. Likely, your Lambda needs less, in which case the amount of traffic needed to make the EC2 more worthwhile higher.

Then your EC2 instance suddenly stops working and your downtime cost you a fat contract that makes the cost of serverless a pocket change.

If you want to compare AWS Lambda with EC2, you need to bring in AWS Load Balancer, Auto Scaling, Security Upgrades for the OS, Healthcheck and many more.

Yes, Lambda is not needed in a lot of context, but if you have the expertise to use it and you want to provide enterprise-grade compliance, it's a walk in the park.

Everything you listed is why I mentioned ECS though. To me it's a perfect in-between.

Bringing the long-lived server back also makes things like long-lived connections, memory caching, cold starts and database connections a non-issue again.

Good points all around.

The costs certainly are not as cut-and-dry as I originally expressed it.

With Lambda you’re in three different Availability Zones by default, so you also need to factor running your proposed EC2 solution in 3 AZs too.

2 cores and 4GB RAM should have no problem handling thousands or tens of thousands of concurrent requests on the JVM. Lambda's documented concurrency maximum is "tens of thousands"[0], which means an 8GB m6g.large or ECS instance can probably handle larger bursts than lambda can. If you had extreme bursts, you'd also be having almost every request hit a cold start.

[0] https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-...

I've been working with Lambda across a few large projects for their API's, with each endpoint being its own lambda.

This has been scaling really well for us and affordability wise it makes the development and testing phase basically free, with the final deployed costs almost never exceeding double digits monthly. This is for multi-az + multi-region deployments too.

Reply on news.ycombinator.com