Hacker News Reader

Comment by CharlieDigital | Hacker News Reader

On GCP and Azure, most folks would be better off running serverless containers via Cloud Run or Container Apps (AWS has no direct equivalent that scales to 0 and incurs no cost).

Both of these scale to zero and offer 180k vCPU/s free per month, 360k GB/s free per month. You incur billing only against the active execution time. Cloud Run Jobs has a whole separate free monthly grant as well.

You can run A LOT for free within those constraints. Certainly a blog or website. To prevent cold starts, just set up Cloud Scheduler (also free for this purpose) to ping the container every few minutes.

Use Supabase for a DB or one of the serverless options (if it works for your data use case) like Firestore, CosmosDB and you can run workloads for a few cents per month with an architecture that will scale easily if you need it to.

6 min video showing the receipts and how easy this is: https://youtu.be/GlnEm7JyvyY

View on HN

The AWS equivalent to Cloud Run and Container Apps is called Fargate, https://aws.amazon.com/fargate/

Neither Fargate nor App Runner scale to zero (unless something changed). So there is always a baseline cost of a few dollars.

Lambda container would be the closest equivalent with that functionality, https://docs.aws.amazon.com/lambda/latest/dg/images-create.h...

Agreed. I ran a small GPT chatbot on Lambda through API Gateway with a dynamodb storage backend and don't recall incurring any cost (or if I did, was just pennies per month).

But if you’re constantly pinging the container (as suggested above), it will never scale to zero.

It "scales to zero" as soon as the request stops as far as billing is concerned.

However, the image remains "warm" and incurs zero cost once the last request ends. So I usually have a `/heartbeat` endpoint for this purpose and point a Cloud Scheduler job at it.

I haven't read the docs to figure out the exact heuristics of when it becomes "cold" again.

Those per-request models usually don’t pan out well. They’re conceptually simple, but you soon realize that you need at least a couple of 24/7 always on boxes and that you only really should use Cloud Run-like services for burstable workloads.

PaaS services or even VM scaling sets with volatile instances can still be stupefyingly cheaper, but that point is really hard to make to architecture astronauts.

    > They’re conceptually simple, but you soon realize that you need at least a couple of 24/7 always on boxes and that you only really should use Cloud Run-like services for burstable workloads.

This is simply not true and Cloud Run-like services offer an easy path for progressive scaling.

1. You can scale it to 0 at the outset as you build your app

2. You can set it to scale to a minimum of n instances (e.g. minimum 1, 2) to have fast response times

3. If you find a need for a 24x7 instance, take the same container image and you can launch a Compute Engine instance with the container directly and scale that way.

4. If you need more control beyond that, move those containers into GKE Autopilot or full GKE or your container orchestrator of choice.

Not only is it easy and free to get started, it provides a straightforward path to adapting the underlying deployment and compute model based on needs as the app scales without the need to pay anything until you actually need 24x7 compute (and even then, it's a matter of setting your Cloud Run service to min=1 instances to get 24x7 compute or configuring a CE instance with the same exact container).

I understand where you're coming from, but not everything speaks HTTP or works on a per-request basis, and PaaS services are still cheaper.

I've seen people shoehorning all sorts of batch processing into HTTP (backed by queues or not) and it has tremendous overhead over just having the cores and RAM there in the same place as the data.

I learned that lesson with Google Apps, and never designed anything to rely solely on HTTP ever again.

Thanks a lot,

Most people think it is easier to use EC2 than FarGate since the first is the most famous one. But actually, it is the other way around!

If it absolutely has to be on AWS, I always go with ECS via (the poorly named) Copilot CLI. Makes it waaaaay easier.

https://aws.github.io/copilot-cli/

Reply on news.ycombinator.com