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.
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.
> 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?
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.
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.
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.
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
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.
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.
> 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?
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.
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.
Skip the docker part I guess? More approachable for new vibe-orientated developers
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...
looks like an answer to Cloudflare Workers
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.
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.
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
A response to App Engine 18 years after its release?
It's the same idea however you characterize it.
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
Being able to handle concurrent requests with one worker is nice. I hope this becomes available for Python too.