> I strongly recommend never using functions as a service unless you genuinely have some client edge compute requirement that absolutely cannot be solved via some other means.

Why? What’s the downside? Are you taking the benefits into account in your calculus? This sort of general, input-free recommendation is junior level thinking at best.

> I am fairly confident I could support more capacity with a single t3a.nano instance.

It depends on what resources those connections are using (memory, CPU, I/O, network). What actual work is being done?

I seem to have had the opposite experience. Using Lambda (I can't speak for many of the other FaaS platforms) is so straightforward to me that there need to be some strong arguments for hosting code/containers in my projects.

My guess is that the IaC is the special sauce that's missing; you do need to go all in with some IaC solution to make using Lambda easy, but it doesn't take a lot of it to make it slick.

Cost/compute is obviously strictly worse for FaaS, but most web workloads don't _really_ need to be optimal.

If you haven't tried Azure Container Apps or GCP Cloud Run, I would strongly recommend trying them at least once deploying any standard web API app in your language of choice, just for your edification.

No adapters needed; just write a web API and ship it. Public URL gets assigned and its ready for use. Code works locally with no special adapters, emulators, or tooling needed. Need to support another cloud plat tomorrow? Ship the same container. Moving it to self-managed K8s? Same container.

It sounds like your are comparing different services.

AWS has Fargate which does the same thing if you are building containers.

https://sliplane.io/blog/comparing-prices-aws-fargate-vs-azu...

It doesn't automatically scale to 0 like Cloud Run and Container Apps. AWS had no analog to CR and CA until this new service.

I find GCP Cloud Run soooo much more pleasant to work with than either AWS Lambda or ECS. Unfortunately most companies don't use GCP.

Agree; Cloud Run has the best ergonomics/economics of all of the serverless container runtimes at the moment. Use it for all of my personal workload when possible.

These one-sided arguments come up every time there's a Lambda thread. They're useful and easily cheaper almost anywhere you have sparse compute or RAM requirements, even for heavyweight tasks like transcoding. A t3.nano meanwhile can simultaneously be overpriced ($3.50 for an idle task) and a bottleneck (30Mbit/s sustained network) in just as many places as a Lambda could be applied incorrectly.

They're also good for extremely bursty loads. I use Lambdas extensively for a radar imagery API that delivers the images for an Android live wallpaper that shows weather radar.

That particular use case can go from hardly any traffic at all to a hurricane of traffic during something like, well, a hurricane.

For consistent processing loads, I think I could save money by just running on dedicated EC2 instances, but you cannot beat the instant scale of Lambdas.

Shameless plug: https://play.google.com/store/apps/details?id=app.radarlove....

There's nothing particularly special about Lambda's scaling. You can do the same with GCP Cloud Run[0] or Azure Container Apps[1]

Specify the maximum number of allowed instances and maximum concurrency per instance. Optionally configure more targeted scale rules. It will scale it from 0 - n as needed.

[0] https://docs.cloud.google.com/run/docs/about-instance-autosc...

[1] https://learn.microsoft.com/en-us/azure/container-apps/scale...

So long as you don't count >2 orders of magnitude difference in scaleup time as particularly special..

That's not how it works since each instance can handle multiple requests (up to 1000 per instance). So you may set this to scale at say 75% load level.

Indeed if you configured each instance as a single threaded handler, you will not have fun.

That's only how it works when misapplying mean() to characterise application performance. In your scenario, every request is hitting either an overloaded instance, or when scaled down, a 20-30 second wait for spin up, better hope they're neither interactive nor some jobs configured with a short timeout. The mechanisms are so completely different they're hard to even make meaningful comparisons between

    > In your scenario, every request is hitting either an overloaded instance,

Why would this be the case? Cloud Run containers and an app runtime like .NET, Java, Go, Rust can inherently be multi-threaded, multi-connection. It can handle up to 1000 concurrent connections per container using just threads and async (assuming sufficient size). Any workload that requires hitting the DB or backend service (S3, etc) is going to I/O bound and sitting in a future most of the time anyways.

The container instances auto-scale by default to a configured n (0 - n) with the option to define specific scale points. If I'm sensitive to high bursts, this can be a matter of scaling at 50% capacity and a warm instance is available while the application still has headway.

Cases where this falls apart: DDoS in which case, I argue that 1) it is better in any case that it falls apart rather than absorbing that type of traffic spike, 2) such traffic is better filtered upstream in any case in an API Gateway + WAF.

I have worked with both types of solutions for different use cases (was invited presenter at Azure Serverless Conf[0]), but my take nowadays is that serverless containers are almost always a better approach since it provides much more flexibility.

[0] https://learn.microsoft.com/en-us/shows/azure-serverless-con...

> this can be a matter of scaling at 50% capacity

At which point we're paying double just to work around cold start latency, which was the original point.

Cloud Run doesn't bill when idle; it only bills when active.

So if you're at 50% capacity with lots of idle time, it can scale to 0.

Scale to 0 doesn't mean "cold". One easy way to keep both Cloud Run and Container Apps "warm" but functionally scaled to 0 for costs is to just ping it every few minutes with Cloud Scheduler set up on a cron pointing to a health endpoint.

If you scale Cloud Run to zero and then send a request, won't you immediately wake it up and be charged until it powers down in at least 15 minutes?

When scale to 0, it only bills when actively serving a request. BUT, the instance doesn't go cold immediately; you are only billed while it is serving even if the instance is active.

This diagram helps visualize: https://www.gstatic.com/bricks/image/5eb3c8e9-6159-4e2f-ba98... (gray bar at the top shows when the instance is started and when it ends; blue bars show actual request, and green bars show the billing)

If there's a 10s gap between requests, you are not billed for the 10s gap, but it is still effectively hot; instance does not stop. Request that comes back in 10s later does not have a startup penalty because the instance is still up.

How do you leverage this to build a high throughput system with no cold starts? Just prime it with a short single request (e.g. `/health`) before instance is stopped.

I assumed you were talking about instance-based billing (what I've always used), but I think you're talking about request-based billing?

Request based billing indeed.

I often hear this argument that it is good for bursty load, but for real, there are a lot of inconvenient limitations. For exemple, you don't really control the number of concurrent instances or the scaling except if you pay for very expensive provisioning.

So you might have to wait for 10s or more to have a new lambda instance spawning up and replying to your requests. And you might have to have your function finish in 15 minutes, deals with the strange concurrency and scaling rules lambda is based on.

> unless you genuinely have some client edge compute requirement that absolutely cannot be solved via some other means

You make it sound like these cases are rare, not sure what kind of work you do but there are markets of all sizes in many different use cases out there.

I feel like what you wanted to say was "I haven't found a need for them" as opposed to "Stay away from it"

Maybe you're trying to say something else we don't know because we don't have your backstory either, did folks at your work tried pushing it for scenarios in which they became a problem? Share that instead as it brings a lot more value to the readers, otherwise it sounds like you are trying to go for a weird flex.

I would agree with OP with "stay away".

The Google paper Towards Modern Development of Cloud Applications[0] does a great job explaining why.

TL;DR the case they make against micro-services architectures (which Lambda encourages):

    1. It hurts performance
    2. It hurts correctness
    3. It is hard to manage
    4. It freezes APIs
    5. It slows down application development

For even a moderately complex system, spreading logic out over multiple discrete runtimes doesn't make sense; instantly run into each of the 5 points. The only times I've found functions useful is truly single-point behavior where we were running some logic connected to CloudFront on each request for some header parsing.

It is certainly possible to write a monolith in Lambda as well, but then that would be bad architecture and a bad fit and I suppose why they are now introducing this new model that is more like GCP Cloud Run or Azure Container Apps.

[0] https://sigops.org/s/conferences/hotos/2023/papers/ghemawat....

They said what they wanted to say, and it was quite clear. The person who commented suggests we don't use client-edge compute unless we have a specific need for it, i.e., don't treat it as a default due to its apparent simplicity up front.

You've taken it in a rather odd direction with the request for a framing more palatable to you.

We don't have to agree, and I guess me understanding it differently could also be like how you understood me in a way I didn't intend to

I agree and disagree with this. I run multiple software platforms that are incredibly bursty, to the level of "no traffic for 10 months out of the year, small traffic of 1-1.5 months, medium for <1 week, and high for 1-2 days" (event-based, like a physical in-person event, not events in the software sense). While I agree lambdas are fiddly and I have some reasons to move off them, they also are kind of perfect for my use case from a billing perspective. Even a t3a.nano would have cost more and not scaled quite as easily as I needed.

All that said, there are times I regret my lambda decision and would prefer just a EC2 host even if it cost more. Deployment would be easier/simpler. I've spent considerable time to improve my deploy process and lower the deploy times but it's still ~2-3min from tag -> deployed which I know I could do faster on just a VM. Also everything gets harder in a lambda, packages/binaries, logging, monitoring, etc.

This is like the Normal Distribution meme: naively, using Lambdas for these services seems like an obvious choice. Once you start getting into the weeds of it, though, you start to realize that there are real trade-offs which make Lambda not as obvious a choice as they appear at first glance. But once you've worked through those pains and complexity, you end up realizing that there's no free lunch and Lambda is actually a great service for these tasks, all things considered.

>> up to 128 concurrent requests per environment > I am fairly confident I could support more capacity with a single t3a.nano instance.

Don't forget that this is referring to 128 concurrent requests per environment. By default, an AWS account can run up to 1,000 concurrent Lambdas, and that number can be increased with support requests.

Of course, the REAL win is that you only pay for what you use. Your t3a.nano is costing you 24/7, and if you want it to scale on demand, your stack will get very complicated very quickly. Lambdas just scale "for free".

Strong disagree, we use lambda/sfn/other services to process hundreds of millions of pages of data annually and it scales beautifully while being mostly hands-free and easy to maintain with a small team.

true that!

I take it as you rarely ever consider tradeoffs when you build your stuff. No good. You are the kinda person who builds, and waste my or companies money and time.

Sometimes things are easily and objectively worse than the alternatives.

that "objectively" portion stems from trade-off discussion.

> Sometimes things are easily and objectively worse than the alternatives.

That's the most subjective thing one can say.

Am I in a postmodernism 101 class or something? No, reality begs to differ.

This is only a single environment for multi-concurrency (compared to previous Lambda Event model which was a single environment per request). Lambda can scale to huge numbers of environments. See https://aws.amazon.com/blogs/compute/exploring-aws-lambda-we... for more information