|
|
|
|
|
|
by rcarmo
603 days ago
|
|
|
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. |
|
|
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).