Looks pretty interesting. I presume the boom in cloudflare workers and other hosting platforms has been a forcing function to make running a web app more “normal” looking with their lambda offering.
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.
> Are we pretending now it's less complicated to distribute an app a cross a variety of lambda functions?
I treat Lambda purely as compute and ignore everything else related to "serverless". My Lambda's are monolith webapps using Axum Rust framework. Using cargo lambda I generate a static binary, upload to s3 and point the lambda at it. Sometimes I'll package as a docker image so can run in Lambda or locally by passing a `--aws-lambda` flag.
If serving HTML i'll use Function URLS with IAM auth and put a Cloudflare worker in front acting as the gateway. I also serve the static assets from cloudfront bucket i.e. static.example.com. Advantage is I use Cloudflare free tier so get denial-of-wallet prevention when my free credits run out. Using IAM auth also means the lambda doesn't execute if for what ever reason someone discovers the url and tries to DoS it so only get charged for the requests not run time.
Yeah I've worked on a website built on a bunch of Lambdas - something like 150 Lambdas that tied themselves in knots with both HTTP requests and message queues.
I ended up moving a bunch of the logic into an ECS-hosted monolith. Probably cost a bit more (warm-up plugins meant that no customers still cost us money) but it vastly simplified things and made scaling up easier (can't set scaling thresholds with Lambda).
Rust + Axum has sort of supported this with a middleware (https://github.com/lazear/axum-aws-lambda). Essentially you write your API as normal, and then when you build for lambda you enable a feature that does the special handler for you.
This + Function URL + Cloudfront, and you end up with an API entirely hosted in lambda. I have a backend that does is hosted like this that does pretty complex work (image/video uploads, image conversions, on top of the standard auth, database connections, etc). It even renders a frontend with HTMX/Alpine.
Even with all the bot traffic I receive, at almost 15 million requests per month the cost is under $10/mo (median latency is roughly 90ms). Cold starts are a non-issue with the Rust runtime.
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.
Everything about running software is made more difficult this way. You might think it would make certain infrastructure aspects easier, but it just changes the semantics of the same problem. It's the same quantity of mess to clean up, but now it's in these really weird piles that are often much harder to access.
> up to 128 concurrent requests per environment
I am fairly confident I could support more capacity with a single t3a.nano instance.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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".
> 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.
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.
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.
> 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 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
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.
Yay ! Active CPU billing mean the same thing as Cloudflare ! But you still pay memory for as long as the function is up. Data transfer is not included, you have to take that into account. There is also the number of requests...
AWS should have understood by now that Cloudflare workers pricng is so much more legible, it's one of the reason of their success.
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!
I have replied to multiple comments. This comment comes from a general response to this thread as a whole lol.
There's not much to say otherwise. It's a pretty standard release from AWS, so other than just explaining AWS as a whole, I don't have anything to offer in general.
This wraps Lambda's 'handler' function and allows express to run on top of it, essentially you get a node web server with no persistence between requests which usually isn't a good thing to rely on, but you can also kinda have that with persistent tcp connections.
Of course since this is not real HTTP, things like WebSocket aren't available, but it's good enough to build a CRUD backend or two.
I know, but as far as the programming experience is concerned, it feels quite similar.
But expensive. Stuff like Api Gateway is just absurd (but necessary since you don't want that stuff to reach your lambdas, which are dog slow to handle). Paying per request is like charging for every breath.
Another big advantage (and I guess the reason this exists), is for some reason, AWS lambda is a hostile environment for node, with its ephemeral VMs, performance is quite bad (much worse than expected)
Interestingly, Google Cloud recommends using Cloud Run (any container) instead of Cloud Functions (upload code). AWS can do that with Lambda too, I wonder why AWS decided to "move backwards" here, as I always found containers are easier and faster to work with?
Both container-way and code-way have the same scalability (code-way is built into a container anyway, just on the cloud). Maybe AWS re-builds the container for security every day?
The page has only a description, no comparisons. The best way to explain a technology is to compare it with something.
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
One of the first blog posts that I have written is about this topic (pardon my bad writing):
"Hosting a hobby project for free without credit card is tough (rant) & here's how I did it (Hugging face)"[0]
I remember trying to evaluate all the options and trying to find a good enough option and there were very few options aside from Vercel and Render or rewriting your application to fit cloudflare workers.
HF spaces is a good option that I had found back then. Also, I recommend having a separate backend service like supabase with HF as if your server is inactive for 24-48 hours, the storage could get wiped out so backend should be seperated.
One of the biggest things that I am proud of was how I broke the nat of intel tiber jupyter using applying a custom patch of bearssh and before it, using junest and ssh and ppng.io, all because I wanted to play minecraft with my friend without credit card :-D
Nowadays, I have a few cheap vps's which makes things so much simpler but I remember that struggle and vercel/render used to help in most cases thus they are so popular.
So I seriously agree with what you are saying based on my experience as well. Though I have to wonder?: I think that the reason that small companies aren't attempting this is because of reasons of scam/spam, but what reasons are there for AWS and others to not do so.
What are the reasons that you think that they don't already provide such service, or do you feel as if this is the natural continuation of it and soon we are gonna see AWS or large hypercloud provider providing free very small compute similar to vercel/render?
Also thanks for making me remember again the blog that I had written :-D
I think big hyperscallers only care about big fish, for example you can get free credits in Azure, provided you have a Visual Studio license, so it is already paid in a way.
Whereas Vercel, Render and co, got to offer such accounts for free due to VC money and trying to get people on board, while fighting against the big names for customer eyes.
Hmm makes sense, though isn't AWS and others realizing the threat that vercel is making constantly towards them while being operated with servers of AWS?
I remember reading about vercel trying to move away from AWS or railway successfully doing so. Their long term end goal still is to migrate away from AWS to capture more juicy margins (or is it? Vsauce music plays)
So with that in mind, has AWS and others realized that providing free credits would be more disruption to actual people paying right now and more loss than whatever Vercel is fighting for?
And if that's the case, then to the investors funding Vercel... Do they know that as well?
Also, I think Vercel has gotten to the point where they are handling spam good-ish but the other alternative railway (not entirely free without credit card yes but still an alternative) still relied on GCP (yes even after their migration/colocation) and GCP's opaque black structures shut down all of railways because of a few accounts doing something malicious.
That is the cost of doing business on someone's else computers and also suppose somebody is creating a new vercel competitor, then they are intentionally targeting themselves as a free alternative and are gonna get free users who intentionally might not pay while facing spam/scam/reputation issues and would need constant maintanence and support. (For example: a guy X creates a scam site targeting Y company at this new Z vercel alternative, the Y company has to contact Z and Z will contact it back and Z has to fix the issues X caused, and there are many more X than what Z can handle)
I am more-so interested though that if Vercel is really a great idea (lure free users etc.) then why aren't others trying the same now and flooding free compute. Is it that the investors who wish to invest in such companies would have better returns in investing in Vercel anyway and have better chances in beating the traditional hyperscalers over establishing a new competitor over Vercel and then over AWS etc.?
If we were to try to arrive at an conclusion or for me to try to learn something new, what could it be?:
Is it that AWS/GCP/Azure are intentionally not becoming a Vercel alternative because they can get away by doing so and its more profitable for them to do so?, and that it's not profitable or even possible for others to do so as well unless they have deep pockets to burn through.
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.
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.
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.
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.
My biased take as the architect of Workers: It's a classic Clay Christensen innovator's dilemma.
V8 isolates seem "worse" on their face (e.g. mostly incompatible with non-JS apps, more difficult to secure), while aiming down-market. The hyperscalers' biggest existing customers aren't asking for them; they are asking for more and better micro VMs to run their existing codebases. It's only the little guys looking to deploy greenfield apps with low ops overhead and on a tight budget that really appreciate the Workers model, and to AWS these seem like small potatoes. Meanwhile there's a huge amount of investment needed to build out this entirely new and different way of doing things (we've been working on it almost a decade now!). In the worst case, this investment is wasted, and in the best case, cannibalizes the existing product line.
There likely many people at AWS who recognize the dilemma, but still cannot push the organization in the right direction. Too much inertia, too many stakeholders who don't get it, because it's unintuitive. When orgs get big they just cannot take disruptive steps, even when they were built on disruption in the past. They only finally come around after the new disruptor is eating their lunch, but by then it's too late.
Reads like absolute tail, after idle period will see a coldstart but due to multi-concurrency the subsequent requests as a burst will be amortized and automatic/proactive scale-up should avoid further coldstarts.
I feel like we're in an age where a very small team of devs armed with enterprise LLM subscriptions could absolutely build and maintain an open source, reverse engineered, self-hosted implementation of all of Amazon's most high profile AWS offerings (S3, SQS, Lambdas, IAM, EC2, DynamoDB, etc.). All as a single, cohesive open source project.
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].
No, not really. You can attach auto scaling to it. But it doesn't scale as fast. And it's not very straightforward to scale to zero. And you have to maintain all of it yourself.
Fargate, just like ECS, doesn't natively scale to zero. You can set the minimum number of instances to zero for both, but there is no native mechanism to scale it back to one when traffic arrives. And especially not one that would hold the connection until the container is ready. Not saying it's impossible... Just not native. And it would require extra resources. So the price won't scale to zero without something like Lambda in front of it.
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.
I guess the event translation step is not needed but I don't see what this gives you over what many of us do today: shove Hono/Express/Fastify into a lambda with some shim/adapter.
It annoys me that when I started with Lambda (2019-ish?) it (at least seemed to) advised against this. I went down the "one function per route/method" path but always disliked it and it added a decent amount of complexity for packaging/deploying. A year or so ago I abandoned that and switched to Fastify (one function instead of 100+) and never looked back. It also makes it easier to test in dev/local and gives me more flexibility to move to a different host in the future.
Weird to see them come around on this but again, what does this give me over what I currently do? It looks like they are just making migrating an existing stack easier (it wasn't that difficult before IMHO).
Disappointed by the NodeJS-only requirement and the 128 req/env/sec ceiling.
NodeJS-only feels very pre-AI. Let me tell my agent to write my web service in Rust/C++/C/Go/Zig, and ship a statically-linked single binary that fits within a maximum binary size ceiling. I'd get much better performance, and make much more of the premium CPU/RAM pricing that I'm being asked to pay in exchange for scale-to-zero and fast autoscaling.
The rest is amazing. First-class support as a CloudFront origin. Easy multi-region and gradual deployment. Clearly, finally, a great response to Cloudflare. Just.... so close, and yet, so far. No way am I going back to Node as a web backend for greenfield projects in 2026.
Lambda can have its place in some architectures. I am not a fan of them in general, I've seen enough giant webs of lambdas that become impossible to truly understand the full architecture as they are split across 100 repos, just a web of slop lambdas. This feels like a canary in a coal mine, if you need this, you really need to start migrating to a standalone service on a machine instead of a lambda, where you are using it wrong.
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.
Looks pretty interesting. I presume the boom in cloudflare workers and other hosting platforms has been a forcing function to make running a web app more “normal” looking with their lambda offering.
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?
MicroVM which I am presuming are firecracker
I believe standard firecracker microvms.
yes it is. hardware virtualization for isolation.
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.
I've written up how they work in practice: https://aws.amazon.com/blogs/compute/exploring-aws-lambda-we... We also have a selection of code samples to try it: https://serverlessland.com/patterns?services=lambda-web-func...
I'm getting a 404 on that blog link, by the way
I found it at: https://aws.amazon.com/blogs/compute/exploring-aws-lambda-we...
I've built 2 applications using Lambdas as a backend and I love how simple and it is. It cost literally 0$ (the lambda part).
The frontend is hosted on cloudfront, the backend is a lambda and you basically just pay for the database and certificate.
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
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.
> Are we pretending now it's less complicated to distribute an app a cross a variety of lambda functions?
I treat Lambda purely as compute and ignore everything else related to "serverless". My Lambda's are monolith webapps using Axum Rust framework. Using cargo lambda I generate a static binary, upload to s3 and point the lambda at it. Sometimes I'll package as a docker image so can run in Lambda or locally by passing a `--aws-lambda` flag.
If serving HTML i'll use Function URLS with IAM auth and put a Cloudflare worker in front acting as the gateway. I also serve the static assets from cloudfront bucket i.e. static.example.com. Advantage is I use Cloudflare free tier so get denial-of-wallet prevention when my free credits run out. Using IAM auth also means the lambda doesn't execute if for what ever reason someone discovers the url and tries to DoS it so only get charged for the requests not run time.
Yes. I found it was simpler to have a "fat" monolithic lambda than split up your logic across multiple lambdas. Easier to deploy, too.
Yeah I've worked on a website built on a bunch of Lambdas - something like 150 Lambdas that tied themselves in knots with both HTTP requests and message queues.
I ended up moving a bunch of the logic into an ECS-hosted monolith. Probably cost a bit more (warm-up plugins meant that no customers still cost us money) but it vastly simplified things and made scaling up easier (can't set scaling thresholds with Lambda).
It's just more effort then I want to or need to.
Just a lambda, a switch in the handler that calls my routes and that's it. I could make it smarter but I don't really need to
> 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
And then stick your code in an OpenFAAS container.
What certificate cost? Acm is free if you don’t export
lambda + DB is an antipattern.
direct connection can be problematic if you dont limit the scaling or don't use rds proxy yes.
The 3 lambda instances aren't going to break your db
Rust + Axum has sort of supported this with a middleware (https://github.com/lazear/axum-aws-lambda). Essentially you write your API as normal, and then when you build for lambda you enable a feature that does the special handler for you.
This + Function URL + Cloudfront, and you end up with an API entirely hosted in lambda. I have a backend that does is hosted like this that does pretty complex work (image/video uploads, image conversions, on top of the standard auth, database connections, etc). It even renders a frontend with HTMX/Alpine.
Even with all the bot traffic I receive, at almost 15 million requests per month the cost is under $10/mo (median latency is roughly 90ms). Cold starts are a non-issue with the Rust runtime.
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.
Everything about running software is made more difficult this way. You might think it would make certain infrastructure aspects easier, but it just changes the semantics of the same problem. It's the same quantity of mess to clean up, but now it's in these really weird piles that are often much harder to access.
> up to 128 concurrent requests per environment
I am fairly confident I could support more capacity with a single t3a.nano instance.
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
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.
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.
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.
[flagged]
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".
> 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):
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 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 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.
[dead]
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
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!
This sort of just feels like those “free PHP hosting” sites you would see in ~2004 now.
Not to say it’s “bad”, just interesting how things loop around.
Feels like they’re placating to those that keep bundling their entire application, php or node, into a single lambda.
Yay ! Active CPU billing mean the same thing as Cloudflare ! But you still pay memory for as long as the function is up. Data transfer is not included, you have to take that into account. There is also the number of requests...
AWS should have understood by now that Cloudflare workers pricng is so much more legible, it's one of the reason of their success.
Jeeze, there's a lot of comments in this thread written by people who have no clue how any of this works lol
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 have replied to multiple comments. This comment comes from a general response to this thread as a whole lol.
There's not much to say otherwise. It's a pretty standard release from AWS, so other than just explaining AWS as a whole, I don't have anything to offer in general.
why not reply and engage with them then rather than posting a vague dismissal?
Something very similar to this was already possible via serverless-express for node:
https://github.com/CodeGenieApp/serverless-express
This wraps Lambda's 'handler' function and allows express to run on top of it, essentially you get a node web server with no persistence between requests which usually isn't a good thing to rely on, but you can also kinda have that with persistent tcp connections.
Of course since this is not real HTTP, things like WebSocket aren't available, but it's good enough to build a CRUD backend or two.
Similar libs exist for other runtimes as well.
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 know, but as far as the programming experience is concerned, it feels quite similar.
But expensive. Stuff like Api Gateway is just absurd (but necessary since you don't want that stuff to reach your lambdas, which are dog slow to handle). Paying per request is like charging for every breath.
Another big advantage (and I guess the reason this exists), is for some reason, AWS lambda is a hostile environment for node, with its ephemeral VMs, performance is quite bad (much worse than expected)
Interestingly, Google Cloud recommends using Cloud Run (any container) instead of Cloud Functions (upload code). AWS can do that with Lambda too, I wonder why AWS decided to "move backwards" here, as I always found containers are easier and faster to work with?
Both container-way and code-way have the same scalability (code-way is built into a container anyway, just on the cloud). Maybe AWS re-builds the container for security every day?
The page has only a description, no comparisons. The best way to explain a technology is to compare it with something.
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.
looks like an answer to Cloudflare Workers
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
Vercel has a big advantage, they are preferred partners from many SaaS vendors, and have hobby accounts without credit card requirements.
Render also doesn't require pay for play.
This is something that big hyperscallers are yet to understand, free to play and then one is hooked, it is much easier to go to the next step.
One of the first blog posts that I have written is about this topic (pardon my bad writing):
"Hosting a hobby project for free without credit card is tough (rant) & here's how I did it (Hugging face)"[0]
I remember trying to evaluate all the options and trying to find a good enough option and there were very few options aside from Vercel and Render or rewriting your application to fit cloudflare workers.
HF spaces is a good option that I had found back then. Also, I recommend having a separate backend service like supabase with HF as if your server is inactive for 24-48 hours, the storage could get wiped out so backend should be seperated.
One of the biggest things that I am proud of was how I broke the nat of intel tiber jupyter using applying a custom patch of bearssh and before it, using junest and ssh and ppng.io, all because I wanted to play minecraft with my friend without credit card :-D
Nowadays, I have a few cheap vps's which makes things so much simpler but I remember that struggle and vercel/render used to help in most cases thus they are so popular.
So I seriously agree with what you are saying based on my experience as well. Though I have to wonder?: I think that the reason that small companies aren't attempting this is because of reasons of scam/spam, but what reasons are there for AWS and others to not do so.
What are the reasons that you think that they don't already provide such service, or do you feel as if this is the natural continuation of it and soon we are gonna see AWS or large hypercloud provider providing free very small compute similar to vercel/render?
Also thanks for making me remember again the blog that I had written :-D
[0]: https://smileplease.mataroa.blog/blog/hosting-a-hobby-projec...
I think big hyperscallers only care about big fish, for example you can get free credits in Azure, provided you have a Visual Studio license, so it is already paid in a way.
Whereas Vercel, Render and co, got to offer such accounts for free due to VC money and trying to get people on board, while fighting against the big names for customer eyes.
Hmm makes sense, though isn't AWS and others realizing the threat that vercel is making constantly towards them while being operated with servers of AWS?
I remember reading about vercel trying to move away from AWS or railway successfully doing so. Their long term end goal still is to migrate away from AWS to capture more juicy margins (or is it? Vsauce music plays)
So with that in mind, has AWS and others realized that providing free credits would be more disruption to actual people paying right now and more loss than whatever Vercel is fighting for?
And if that's the case, then to the investors funding Vercel... Do they know that as well?
Also, I think Vercel has gotten to the point where they are handling spam good-ish but the other alternative railway (not entirely free without credit card yes but still an alternative) still relied on GCP (yes even after their migration/colocation) and GCP's opaque black structures shut down all of railways because of a few accounts doing something malicious.
That is the cost of doing business on someone's else computers and also suppose somebody is creating a new vercel competitor, then they are intentionally targeting themselves as a free alternative and are gonna get free users who intentionally might not pay while facing spam/scam/reputation issues and would need constant maintanence and support. (For example: a guy X creates a scam site targeting Y company at this new Z vercel alternative, the Y company has to contact Z and Z will contact it back and Z has to fix the issues X caused, and there are many more X than what Z can handle)
I am more-so interested though that if Vercel is really a great idea (lure free users etc.) then why aren't others trying the same now and flooding free compute. Is it that the investors who wish to invest in such companies would have better returns in investing in Vercel anyway and have better chances in beating the traditional hyperscalers over establishing a new competitor over Vercel and then over AWS etc.?
If we were to try to arrive at an conclusion or for me to try to learn something new, what could it be?:
Is it that AWS/GCP/Azure are intentionally not becoming a Vercel alternative because they can get away by doing so and its more profitable for them to do so?, and that it's not profitable or even possible for others to do so as well unless they have deep pockets to burn through.
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.
> I believe Cloudflare is the only FaaS that offers that
Wasmer also offers the same (charging only for active CPU usage), with the advantage that you can run full Node.js and Python workloads
https://wasmer.io/
And there are even hibernateable websockets too - only paying for when data is actually transferring.
And the maximum worker time is based on processing time, not wall time.
Lambda Web Functions, per the article, and Vercel Fluid Compute also do this.
https://vercel.com/fluid
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.
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.
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.
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.
Why doesnt Amazon or any hyperscale replicate Workers? After all they all have the scale of infrastructure
My biased take as the architect of Workers: It's a classic Clay Christensen innovator's dilemma.
V8 isolates seem "worse" on their face (e.g. mostly incompatible with non-JS apps, more difficult to secure), while aiming down-market. The hyperscalers' biggest existing customers aren't asking for them; they are asking for more and better micro VMs to run their existing codebases. It's only the little guys looking to deploy greenfield apps with low ops overhead and on a tight budget that really appreciate the Workers model, and to AWS these seem like small potatoes. Meanwhile there's a huge amount of investment needed to build out this entirely new and different way of doing things (we've been working on it almost a decade now!). In the worst case, this investment is wasted, and in the best case, cannibalizes the existing product line.
There likely many people at AWS who recognize the dilemma, but still cannot push the organization in the right direction. Too much inertia, too many stakeholders who don't get it, because it's unintuitive. When orgs get big they just cannot take disruptive steps, even when they were built on disruption in the past. They only finally come around after the new disruptor is eating their lunch, but by then it's too late.
Probably because their solution is technically superior from a safety perspective?
And appengine
A response to App Engine 18 years after its release?
It's the same idea however you characterize it.
In this thread: "If my grandma had wheels, she'd be a bike."
> a burst of incoming traffic can share warm environments instead of mapping each request to a new one
But cold starts could still occur, especially in a low-traffic environment where requests come in seldomly?
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...
SnapStart doesn't support Node.js (unfortunately?), only Java, Python, .NET
https://docs.aws.amazon.com/lambda/latest/dg/snapstart-runti... has instructions for SnapStart with Node. But yes it's more hoops.
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...
Reads like absolute tail, after idle period will see a coldstart but due to multi-concurrency the subsequent requests as a burst will be amortized and automatic/proactive scale-up should avoid further coldstarts.
I feel like we're in an age where a very small team of devs armed with enterprise LLM subscriptions could absolutely build and maintain an open source, reverse engineered, self-hosted implementation of all of Amazon's most high profile AWS offerings (S3, SQS, Lambdas, IAM, EC2, DynamoDB, etc.). All as a single, cohesive open source project.
Just feed it the API docs and loop.
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...
> 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?
AWS also tends to have hardware that is available for you to use.
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.
Finally. The need of API gateway + lambda combo even for POCs was almost cliche.
Being able to handle concurrent requests with one worker is nice. I hope this becomes available for Python too.
How is this different from a container?
The scaling part. You don't need to do anything. It just runs as many instances of the Lambda as needed for you.
Does Elastic Container Service not do that?
No, not really. You can attach auto scaling to it. But it doesn't scale as fast. And it's not very straightforward to scale to zero. And you have to maintain all of it yourself.
Fargate does, though. And it's been doing it for at least 5 years, if not more.
Fargate, just like ECS, doesn't natively scale to zero. You can set the minimum number of instances to zero for both, but there is no native mechanism to scale it back to one when traffic arrives. And especially not one that would hold the connection until the container is ready. Not saying it's impossible... Just not native. And it would require extra resources. So the price won't scale to zero without something like Lambda in front of it.
Skip the docker part I guess? More approachable for new vibe-orientated developers
It’s one isolated process per request.
In a container the memory/cpu is shared for all incoming requests.
It supports 128 simultaneous requests web function; and many more if they are serial. It also supports multiple processes per function.
[flagged]
Finally Lambda without the adapter layer.. Now please add .NET and Java with those concurrent requests
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:
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...
[flagged]
I guess the event translation step is not needed but I don't see what this gives you over what many of us do today: shove Hono/Express/Fastify into a lambda with some shim/adapter.
It annoys me that when I started with Lambda (2019-ish?) it (at least seemed to) advised against this. I went down the "one function per route/method" path but always disliked it and it added a decent amount of complexity for packaging/deploying. A year or so ago I abandoned that and switched to Fastify (one function instead of 100+) and never looked back. It also makes it easier to test in dev/local and gives me more flexibility to move to a different host in the future.
Weird to see them come around on this but again, what does this give me over what I currently do? It looks like they are just making migrating an existing stack easier (it wasn't that difficult before IMHO).
Disappointed by the NodeJS-only requirement and the 128 req/env/sec ceiling.
NodeJS-only feels very pre-AI. Let me tell my agent to write my web service in Rust/C++/C/Go/Zig, and ship a statically-linked single binary that fits within a maximum binary size ceiling. I'd get much better performance, and make much more of the premium CPU/RAM pricing that I'm being asked to pay in exchange for scale-to-zero and fast autoscaling.
The rest is amazing. First-class support as a CloudFront origin. Easy multi-region and gradual deployment. Clearly, finally, a great response to Cloudflare. Just.... so close, and yet, so far. No way am I going back to Node as a web backend for greenfield projects in 2026.
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...
Yep, I see container support is marked coming soon: https://github.com/aws/aws-lambda-roadmap/issues/103 This is your killer feature!
Lambda can have its place in some architectures. I am not a fan of them in general, I've seen enough giant webs of lambdas that become impossible to truly understand the full architecture as they are split across 100 repos, just a web of slop lambdas. This feels like a canary in a coal mine, if you need this, you really need to start migrating to a standalone service on a machine instead of a lambda, where you are using it wrong.
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.
This looks suspiciously like Vercel's fluid compute..
is there a selfhosted alternative ?
[flagged]
[dead]