See https://cloud.google.com/secret-manager/
I recommend this community-maintained FAQ on Cloud Run:
You can run worker code by moving them into individual HTTP calls, triggered by whatever workflow you want. Cloud Tasks, PubSub, Cron, etc.
Google Cloud isn't someone's side project though so the risk is much lower. You're right that services can be shut down at moment's notice but that applies to any service of any kind. Unless you host with multiple cloud providers at the same time you cannot avoid that risk.
There was also a similar one for Mozilla: 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.
The petty snipe is not necessary or appreciated.
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.
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.
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.