The big miss for me is a shell into a running cloud run container, which you can’t do even with reserved cpus yet.

Getting dramatiq (a python sidekiq equivalent) running on the CPU-reserved containers was pretty excruciating. They recommend that functionality for background jobs, but cloud run still needs an HTTP-bound port to know whether apps are running, and also the sandboxing in the gen1 instances didn't work with dramatiq (not sure what, something about forking I imagine?). The error trail was useless for it. Gen2 instances worked. They're also pretty expensive, start at like $40/month for a tiny 1cpu/256mb instance? It's a non-shared CPU, but that's pricey! Memorystore is pricey for bootstrapping too, the cheapest instance is like $35?

Other than that it has been okay. There are some weird surprises, like needing to spin up a VPN connector to hit memorystore on non-public endpoints. (Because surprise! GCP serverless doesn’t run in a VPC you have an iota of control over.) Some friction like that they need to have better defaults for.

Suffice to say, all these things mean the experience is still way, way higher friction than heroku was a decade ago. I'm hopeful they'll keep iterating though.

Yeah that’s def a little gotcha.

Google just announced “jobs” for Cloud Run which is nice but yeah not ssh into an instance.

Then again if you’re using the official google buildpack or your own Dockerfile you can just run it locally

Well, I was trying to diagnose that redis issue specifically, hah! So being in the running environment was exactly what I needed in order to understand the issue.

My temporary fix has been to run a container OS vm instance and run the container, but connecting sql, secrets, etc from my cloud run env is painful (the whole thing I'm leaning on cloud run for in the first place)

I would love to use the new jobs 100% but they're preview in europe-west9 only, both oddly specific and useless for me, heh.

I'm pretty spike on google cloud as a whole though. Interop between their services is getting pretty great, and for me it's simpler than AWS. Their addition of AlloyDB fixes the one thing that kind of scared me about having to move in the future too!

Cloud Run is awesome, probably the best "megacloud" container/serverless product. But compared to Heroku it still leaves a lot on the table when it comes to developer experience. Stuff like: long-running workers, crons (they're just fixing this in beta this week), ability to get a shell to run arbitrary commands, having multiple environments, auto-configuration of sql/redis connections. Then if you're doing a "real" production-grade app you have to deal with how you orchestrate multiple cloud run instances behind a load balancer (e.g. frontend/backend) and how you deal with CI/CD across multiple environments for that plus all the problems above. Even Heroku has many of the 2nd class of issues (as do the other PaaS that have copied them). Next-gen PaaS like render or railway solve some of these issues, but then you're left with the most critical Heroku issue - lock-in and inability to extend beyond the closed walls of the platform.

For all these reasons, we're building Coherence (www.withcoherence.com). Our first version actually uses Cloud Run - it sounds like we'd solve a lot of your particular problems! But we are also going to offer AWS/Fargate and other deployment targets - since all these platforms have similar issues at this time. The idea is too package up a solution to these issues that goes from dev to production for real-world applications built by serious teams. To democratize a first-class developer experience without all the compromise.

As decent as Cloud Run is (and it is nice, AFAICT the most pleasant/productive container deployment thing out there atm), CloudSQL is a tire fire, especially the complete lack of tooling and connectivity if your database is within a VPC.

Came here to say this also. You can pretty easily replicate the Heroku workflow with Buildpacks and cloud run and end up with a much better service in the process.