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