4 ms·

if you're spending less than 2$ per month how much traffic -> how much money can you make? Sure, I also have plenty of static websites hosted for free by verce

if you're spending less than 2$ per month how much traffic -> how much money can you make? Sure, I also have plenty of static websites hosted for free by vercel / netlify / heroku / yourpick and even free functions. As soon as you start hitting traffic, functions start to cost a lot vs your own vps. My ideal setup right now is free static hosting from the marketing budget of friendly saas, free cloudflare on top and then APIs hosted on small vps (I have plenty of stuff on digitalocean but if I were to start from scratch I'd go fully with hetzner). I avoid the big 3 as much as I can and I laugh for hours when I see the bills of clients using them.

CharlieDigital 4y ago
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 4y ago
  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 4y ago
    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 https://github.com/CharlieDigital/dn6-firebase [1] https://github.com/aertje/cloud-tasks-emulator https://github.com/aertje/cloud-tasks-emulator [2] https://localstack.cloud/ https://localstack.cloud/
    - friendly_deer 4y ago
      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 4y ago
    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 https://martinfowler.com/bliki/IntegrationTest.html
    - friendly_deer 4y ago
      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 4y ago
        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

CharlieDigital 4y ago

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 4y ago
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 4y ago
  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 https://github.com/CharlieDigital/dn6-firebase [1] https://github.com/aertje/cloud-tasks-emulator https://github.com/aertje/cloud-tasks-emulator [2] https://localstack.cloud/ https://localstack.cloud/
  - friendly_deer 4y ago
    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 4y ago
  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 https://martinfowler.com/bliki/IntegrationTest.html
  - friendly_deer 4y ago
    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 4y ago
      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