YHK - yet another hacker news clone

Yes.

> Lambda scales down to zero environments when there is no traffic. The next request after that starts a new environment (a cold start).

https://docs.aws.amazon.com/lambda/latest/dg/web-functions-s...

Presumably it can be combined with SnapStart

There was also this a week ago, maybe you can combine this with containers? https://aws.amazon.com/blogs/compute/get-started-with-aws-la...

I had the same impression that this is an answer to Cloudflare workers success, but are AWS Lamba web functions hosted in containers or WASM?

Yeah, I'm a bit confused why this is profound. Don't plenty of services already offer this?

But maybe I'm dumb or missing something.

Also vercel, railway, render etc

Cloudflare workers wasn’t always an 1:1 option for simple hosting (iirc) and people used to think it was more complicated than vercel etc but it has changed in recent years and right now they have made things smoother and simpler to compete with vercel and others.

Now that AWS has entered into the field as well, given that vercel and others already build on top of AWS. It will be interesting to see how this all goes.

I wonder if more og hyper scalers like say hetzner/ovh and others will also target this audience

Isn't this a move in the other direction. Workers and traditional Lambda need to you write short lived event handlers; this is about running a standard server.

And appengine

Absolutely, and the offer is better in terms of DX (no need for an adapter) and it’s not limited to 128MB of memory.

Exciting times, I can’t wait for Cloudflares response.

Google Cloud Run and Azure Container Apps feels like the closest analogues.

Both allow deployment of web apps without an adapter layer. Both scale to zero (really useful for hobby apps; small internal apps that do not get sustained traffic, but can get bursty). Both allow concurrency control.

Cloud Run "family" is quite a nice way of managing serverless ("orchestrationless"?) containers. Cloud Run worker pools for background workers that connect to Pub/Sub. Cloud Run jobs for long running tasks like extracts, ETL. Cloud Run instances (newer offering) for always on agents.

The real advantage of cloudflare workers is you don’t pay for the processing time while you’re waiting for upstream network responses.

I believe Cloudflare is the only FaaS that offers that. It makes it fantastic for putting a light weight layer in front of a few upstream API, like say inference providers.

but this is built on firecracker vm. while Cloudflare workers are built on v8 isolates. at the moment Cloudflare workers have no equivalent. Deno was the only one trying to do the same.

what will be interesting to see is startup times.

Skip the docker part I guess? More approachable for new vibe-orientated developers

The scaling part. You don't need to do anything. It just runs as many instances of the Lambda as needed for you.

It’s one isolated process per request.

In a container the memory/cpu is shared for all incoming requests.

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.

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.

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

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

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

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

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.

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.

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

Cloud Run says "Hi"

Edit: even better for .NET and Java as Cloud Run supports startup CPU boost[0] to improve initial cold start JIT performance.

What this looks like deploying a .NET web API to Cloud Run:

    # Auth first: gcloud auth configure-docker us-central1-docker.pkg.dev
    # Package and push using .NET tools (built in)
    dotnet publish --os linux --arch x64 /t:PublishContainer \
      -p ContainerRegistry=us-central1-docker.pkg.dev \
      -p ContainerRepository=ORG/REG/IMG \
      -c Release

    # Deploy web API to Cloud Run
    gcloud run deploy SVC \
      --image=us-central1-docker.pkg.dev/ORG/REG/IMG:latest \
      --project=PROJ \
      --region=us-central1 \
      --cpu-boost \
      --max-instances=2 \
      --min-instances=0

    # Get back a URL to the ingress

I run a bunch of workloads "for free" because most apps are going to fall into the monthly credit pool (180k vCPU seconds; 50h @ 1 vCPU) if it scales to 0.

[0] https://cloud.google.com/blog/products/serverless/announcing...

Feels like they’re placating to those that keep bundling their entire application, php or node, into a single lambda.

> feel like we're in an age where a very small team of devs armed with enterprise LLM subscriptions

Ok, but who is paying them?

Sure... but the point with using AWS is that I don't have to self-host these services lol

Like, most of these services already have proper open-source alternatives you're free to use on your own hardware or even on AWS.

You’re pretty much describing LocalStack [1].

IMO much of the product’s success was derived from the extensive snapshot + behavioural tests they created to validate parity with AWS.

The basic engineering loop was: 1. Write tests against AWS 2. Record all results 3. Run tests from (1) against emulator and diff with results from (2)

Like, theoretically, you could use their preexisting suite of tests to construct a pretty decent emulator, since the engineering + cloud costs of recording behavior has already been frontloaded, and resides within their snapshot files [2].

[1] https://github.com/localstack/localstack

[2] https://github.com/localstack/localstack/tree/main/tests/aws...

why not reply and engage with them then rather than posting a vague dismissal?

I don't mean to pile on (given the reply by awithrow) but maybe it's worth repeating the principle: if you know more than others do, that's great, but in that case please share some of what you know, so the rest of us can learn!

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

I agree they can get bad but it's so nice to be able to take event driven workflows, like "pick up this file just written to S3, do some stuff to it, and write results out somewhere", and just have it work with basic features like autoretry, DLQs, built-in logging, etc.

Stringing together a bunch is an anti-pattern IMO but when it's not being abused, it's wonderful tech.

> I don't want to manage a server or even a docker image. I just want my code to exist there so I like the idea

agree, unfortunately in practice it's more common to throw the api behind k8s with containers

What certificate cost? Acm is free if you don’t export

lambda + DB is an antipattern.

Are we pretending now it's less complicated to distribute an app a cross a variety of lambda functions? So how are you deploying it? Serverless Framework? SST? Mounting complexity compared to a container... There are also a bunch of services that let you simply host a container, no server to manage. Distributing apps on lambda is a classic trap, and also just because you can, doesn't mean you should. You will quickly find out local development, deployment, debugging, monitoring is all more complex and you will wonder how you got there.

It should just accept a docker container (which normal lambdas can) or a WASM blob that exposes HTTP over a standard port.

Could use optional headers for extra integration points (eg. better per-request resource usage tracking for scaling).

Thanks, Have a look at our Lambda roadmap for Web Functions which shows some of the things we're already working on: https://github.com/orgs/aws/projects/286/views/1?filterQuery...

That's just an adapter. This new AWS offering allows concurrent connections, and CPU billing vs wall clock time. It's not the same.

I'm getting a 404 on that blog link, by the way

Presumably something like cloudworkers has caused customers to ask for it?

I agree, lambdas can currently run code, run containers, or fargate for containers.

I guess someone managed to find a usecase that wasn't quite covered.