7 ms·

This is spot on, except for one thing: Google Cloud Run. It's the closest offering I've found to Heroku and am planning to migrate all our services to it due t

This is spot on, except for one thing: Google Cloud Run. It's the closest offering I've found to Heroku and am planning to migrate all our services to it due to significantly better pricing. Make sure you look into it.

blaisio 6y ago
Google Cloud Run doesn't provide nearly the same features as Heroku. For example, there is no easy way to manage secrets with Cloud Run. There is no way to run a worker process. Integration with other Google Cloud things like Cloud SQL is clunky. Cloud Run is okay to get started but almost all apps will need more.
- fdweitendorf 6y ago
  How would you like to see the integration with Cloud SQL improved?
- jsmeaton 6y ago
  We've been successfully using Cloud Tasks and firing payloads right back at our HTTP cloud run service to solve for the lack of background workers. We had to build a mini-framework around it, but it works surprisingly well. https://cloud.google.com/tasks https://cloud.google.com/tasks
- manigandham 6y ago
  It's built around everything being an HTTP request, and billing for the continuous seconds of time the app needs to run to service those calls. You can run worker code by moving them into individual HTTP calls, triggered by whatever workflow you want. Cloud Tasks, PubSub, Cron, etc.
- tomd 6y ago
  > there is no easy way to manage secrets with Cloud Run See https://cloud.google.com/secret-manager/ https://cloud.google.com/secret-manager/ I recommend this community-maintained FAQ on Cloud Run: https://github.com/ahmetb/cloud-run-faq https://github.com/ahmetb/cloud-run-faq
Chloro 6y ago
Recently discovered cloud run and it's absolutely amazing. I will be using it for as much as possible going forward. Cheap, easy, scaling. For a crud app it does everything you could ever want.
Larrikin 6y ago
The Google part of the name means that the service could be shut down at moment's notice if it isn't providing millions of dollars in revenue and even then it's a toss up if the people in charge get bored of it.
- google234123 6y ago
  What Google Cloud product has been shutdown prematurely? You still mad about the Google RSS reader?
  - Karunamon 6y ago
    Google seemingly kills more products than they run and I wouldn't rely on them for any aspect of my business, based on this, and their historically awful CS. The petty snipe is not necessary or appreciated.
  - karlp 6y ago
    First one I found: https://en.m.wikipedia.org/wiki/Google_Cloud_Print https://en.m.wikipedia.org/wiki/Google_Cloud_Print
    - manigandham 6y ago
      That was never a part of Google Cloud. It was a feature of Chrome browser/OS and allowed for sharing printers over the internet because of the limitations back in 2010. Google has a terrible reputation with consumer services but has been pretty decent with Google Cloud so far. The biggest negative example would be Google Maps pricing changes but that seems to be different class of issue.
  - KronisLV 6y ago
    There was a thread the other day that mentioned a variety of products that were killed by Google, which were aggregated here: https://killedbygoogle.com/ https://killedbygoogle.com/ There was also a similar one for Mozilla: https://killedbymozilla.com/ https://killedbymozilla.com/ Perhaps they were being weary due to the practices the entirety of the company has displayed in the past, in regards to killing off products. Not sure about Google Cloud in particular, though.
jillesvangurp 6y ago
Agreed; we reduced our cost from close to 50$/month to a few dollars per month by simply switching from google app engine to cloud run. The initial reason for switching was that I wanted a dockerized solution so that we are not locked in to arbitrary versions of whatever app engine supports. It does that. But the cost advantage makes it a pretty sweet deal. Cloud run is very easy to get started with. It's basically a service that runs and scales a docker based application. They bill per request based on some notional cost of cpu and memory. They give you some options for using bigger instances, which influences the per request cost. You can go from 256MB to 2GB memory and I think you can have up to 2 or 4 vcpus (one of those, we use 1). You can specify a minimum (default 0) and a maximum (default 1000) number of instances. If a request comes in and nothing is running, it starts an instance. After idling a while it disappears again. So, if you get a low amount of traffic, mostly there will be something running without costing too much. At some point you raise the minimum to 1 instance and it starts costing a bit more. Crucially, there is a freemium layer: you don't get charged unless you hit a certain amount of requests. So, when prototyping, this is very cheap. Basically we managed to keep our cost around a few dollars while in the last months. As this is part of Google cloud, you can transition to other solutions (like their hosted kubernetes) eventually. You also have access to other stuff. E.g. we use firestore as a cheap (but limited) database and the google secret store for secrets, and some storage buckets. When you click together a cloud run deployment, it can create a cloud build for you that points to your git repository and set up automated deployments. If you have a Dockerfile, it will try to build and deploy that. If you need to customize what the build does, you can provide a custom cloudbuild yaml file (similar to github actions, travis-ci, and other popular ci options). After it comes up, you get a nice https endpoint. You can actually add password protection to that as well if you need it. And you can optionally use your own domain. So, we are running a spring-boot project for next to nothing. When the time comes, we'll likely swap out firestore for a proper database as this may get expensive as they bill per read and write and certain operations are just going to use up a lot of reads (e.g. a count operation). It's fine as a dumb key value store but it is very limited in terms of other features (e.g. querying). However, Google's hosted databases are expensive and don't really make sense until you are ready to spend a few hundred dollars per month. Same with Kubernetes. Kubernetes does not make sense until you are ready to commit to a burn rate of hundreds of dollars per month. And it's completely overkill unless you actually are deploying multiple things.

blaisio 6y ago

Google Cloud Run doesn't provide nearly the same features as Heroku. For example, there is no easy way to manage secrets with Cloud Run. There is no way to run a worker process. Integration with other Google Cloud things like Cloud SQL is clunky. Cloud Run is okay to get started but almost all apps will need more.

fdweitendorf 6y ago
How would you like to see the integration with Cloud SQL improved?
jsmeaton 6y ago
We've been successfully using Cloud Tasks and firing payloads right back at our HTTP cloud run service to solve for the lack of background workers. We had to build a mini-framework around it, but it works surprisingly well. https://cloud.google.com/tasks https://cloud.google.com/tasks
manigandham 6y ago
It's built around everything being an HTTP request, and billing for the continuous seconds of time the app needs to run to service those calls. You can run worker code by moving them into individual HTTP calls, triggered by whatever workflow you want. Cloud Tasks, PubSub, Cron, etc.
tomd 6y ago
> there is no easy way to manage secrets with Cloud Run See https://cloud.google.com/secret-manager/ https://cloud.google.com/secret-manager/ I recommend this community-maintained FAQ on Cloud Run: https://github.com/ahmetb/cloud-run-faq https://github.com/ahmetb/cloud-run-faq

Chloro 6y ago

Recently discovered cloud run and it's absolutely amazing. I will be using it for as much as possible going forward. Cheap, easy, scaling. For a crud app it does everything you could ever want.

Larrikin 6y ago

The Google part of the name means that the service could be shut down at moment's notice if it isn't providing millions of dollars in revenue and even then it's a toss up if the people in charge get bored of it.

google234123 6y ago
What Google Cloud product has been shutdown prematurely? You still mad about the Google RSS reader?
- Karunamon 6y ago
  Google seemingly kills more products than they run and I wouldn't rely on them for any aspect of my business, based on this, and their historically awful CS. The petty snipe is not necessary or appreciated.
- karlp 6y ago
  First one I found: https://en.m.wikipedia.org/wiki/Google_Cloud_Print https://en.m.wikipedia.org/wiki/Google_Cloud_Print
  - manigandham 6y ago
    That was never a part of Google Cloud. It was a feature of Chrome browser/OS and allowed for sharing printers over the internet because of the limitations back in 2010. Google has a terrible reputation with consumer services but has been pretty decent with Google Cloud so far. The biggest negative example would be Google Maps pricing changes but that seems to be different class of issue.
- KronisLV 6y ago
  There was a thread the other day that mentioned a variety of products that were killed by Google, which were aggregated here: https://killedbygoogle.com/ https://killedbygoogle.com/ There was also a similar one for Mozilla: https://killedbymozilla.com/ https://killedbymozilla.com/ Perhaps they were being weary due to the practices the entirety of the company has displayed in the past, in regards to killing off products. Not sure about Google Cloud in particular, though.

jillesvangurp 6y ago

Agreed; we reduced our cost from close to 50$/month to a few dollars per month by simply switching from google app engine to cloud run. The initial reason for switching was that I wanted a dockerized solution so that we are not locked in to arbitrary versions of whatever app engine supports. It does that. But the cost advantage makes it a pretty sweet deal. Cloud run is very easy to get started with. It's basically a service that runs and scales a docker based application. They bill per request based on some notional cost of cpu and memory. They give you some options for using bigger instances, which influences the per request cost. You can go from 256MB to 2GB memory and I think you can have up to 2 or 4 vcpus (one of those, we use 1). You can specify a minimum (default 0) and a maximum (default 1000) number of instances. If a request comes in and nothing is running, it starts an instance. After idling a while it disappears again. So, if you get a low amount of traffic, mostly there will be something running without costing too much. At some point you raise the minimum to 1 instance and it starts costing a bit more. Crucially, there is a freemium layer: you don't get charged unless you hit a certain amount of requests. So, when prototyping, this is very cheap. Basically we managed to keep our cost around a few dollars while in the last months. As this is part of Google cloud, you can transition to other solutions (like their hosted kubernetes) eventually. You also have access to other stuff. E.g. we use firestore as a cheap (but limited) database and the google secret store for secrets, and some storage buckets. When you click together a cloud run deployment, it can create a cloud build for you that points to your git repository and set up automated deployments. If you have a Dockerfile, it will try to build and deploy that. If you need to customize what the build does, you can provide a custom cloudbuild yaml file (similar to github actions, travis-ci, and other popular ci options). After it comes up, you get a nice https endpoint. You can actually add password protection to that as well if you need it. And you can optionally use your own domain. So, we are running a spring-boot project for next to nothing. When the time comes, we'll likely swap out firestore for a proper database as this may get expensive as they bill per read and write and certain operations are just going to use up a lot of reads (e.g. a count operation). It's fine as a dumb key value store but it is very limited in terms of other features (e.g. querying). However, Google's hosted databases are expensive and don't really make sense until you are ready to spend a few hundred dollars per month. Same with Kubernetes. Kubernetes does not make sense until you are ready to commit to a burn rate of hundreds of dollars per month. And it's completely overkill unless you actually are deploying multiple things.