[CharlieDigital]

Google Cloud Run pricing is:

- 2 million requests/mo free

- First 180,000 vCPU seconds free

- First 360,000 GiB seconds free

Then:

- $0.000024 /vCPU seconds

- $0.0000025 /GiB seconds

- $0.40 per million requests

This will get you pretty far for $2/mo. Within the free tier itself, assuming you can process each request in 250ms on a 1 vCPU container, you get 720,000 requests before you start paying for compute usage. Each $1.00 is another ~38,000 vCPU seconds (@1 GiB second) or ~152,000 requests @ 250ms per request.

Roughly speaking, $2/mo. is 1 million requests @ 250ms each request consuming 1 GiB seconds on a 1 vCPU container.

(There's some nominal cost for egress and storage of container images).

[friendly_deer]

The thing that holds me back from Google cloud run Is that it is difficult to replicate that exact environment locally for testing and dev. If you’re working with stateless apps then that’s fine, But what is the typical local workflow of developing against a database, task Queue, etc.?

[CharlieDigital]

Which database?

If you're going all-in on Google Cloud and using Firestore, then use the emulators [0]. The emulators includes Pub/Sub. For Cloud Task Queues, use an unofficial emulator [1]

If you're not going all-in on Google Cloud and say you want to use Postgres, then use a `docker-compose.yaml` file and pull in a Postgres container instance or run a local Postgres if you want. Then pick a free Postgres compatible cloud service for the actual runtime (e.g. Supabase free tier). Same goes for MySQL.

For AWS, I'd use LocalStack [2]

[0] https://github.com/CharlieDigital/dn6-firebase

[1] https://github.com/aertje/cloud-tasks-emulator

[2] https://localstack.cloud/

[friendly_deer]

Thank you for the reply. That makes sense… I guess something about me just likes the purity of running the exact same container on my local machine as would be in prod, but yeah I agree that at some scale that doesn't work.

[nijave]

If you're using an IaC tool like Terraform or Pulumi, you can just setup/tear down test resources on demand (for integration/acceptance tests). Under normal usage, hopefully you can get away with mocks/stubs/fakes. Some development frameworks make this a lot easier than others

Using real resources is usually fine for smaller applications but can be very problematic as your application grows. With that in mind, it's good to create boundaries so you limit the amount of "real infrastructure" you need to test/deploy. Reference https://martinfowler.com/bliki/IntegrationTest.html

[friendly_deer]

Thanks for taking the time to reply. Yeah ideally we always use real resources to mirror prod closely, but I see your point that that won’t always be possible as the app grows.

[nijave]

Another balance is to just use real resources in CI with some concurrency control to make sure a single build runs at once. Locally, you continue to use mocks/stubs/fakes

You still get assurance from testing but reduce the amount of places you run the "expensive" (time, resource, $) tests