Comment by CharlieDigital | Hacker News Reader

Comment by CharlieDigital | Hacker News Reader

Parent Full thread

On Google Cloud, the secret sauce seems to be:

    - Google Firebase Hosting for your static front-ends
    - Google Cloud Run Services for your APIs
    - Google Cloud Run Jobs for long running compute (more than doubles your Cloud Run monthly free compute grant if you can move some compute workloads into a Job)
    - Google Firestore for anything that doesn't benefit from being relational
    - Supabase for anything that benefits from being relational and/or you need a vector DB.

You can get pretty far with this combo without paying more than a few cents a month and you don't compromise on scalability nor portability (excluding Firestore).

(I'd avoid Cloud Functions because the cold starts are abysmal and you'll end up paying a small fee for warm instances for anything that is latency sensitive; proper Cloud Run at least has a CPU boost option that seems to help).

> Google Cloud Run Services for your APIs

what about the cold start? i've worked on a project that uses cloud run to serve up a django app. has a terrible cold start. it gets a little better if you script a ping but it's still noticeable

I use it with .NET 7 and cold starts are acceptable for me.

Part of that is enabling the CPU Boost since .NET and Java are both JIT runtimes. The CPU Boost seems like -- seat of the pants -- about a 50% reduction in cold start times.

You can give the CPU Boost a try and see if it makes a difference, but it may also be dependent on your framework's startup flow.

> Cloud Functions

I think I read somewhere that Cloud Functions are just Cloud Run under the hood anyways, so just use Cloud Run lol.

Gen 2 Cloud Functions are deployed into Cloud Run.

But you end up with an abstraction layer (Functions) that adds to the startup cost and less control over the configuration.

There are some benefits like ease of local development and testing since it integrates really nicely into the emulator suite and also integrates handling of authz/authn into the pipeline. But otherwise, I'd recommend Cloud Run for more portability and better control over parameters that affect cost and performance.

Extreme vendor lockin! Great advice...

Not really; Cloud Run is just a container with port 8080 exposed; there's no special code or dependencies.

You can move it easily to AWS App Runner, Azure Container Apps, or your own K8s cluster.

I build for clients using Cloud Run (faster to deploy during testing), but then ship to AWS App Runner or ECS for customers.

good summary. I've used a bunch of this stack.

Reply on news.ycombinator.com