Hacker News Reader

Comment by emilsedgh | Hacker News Reader

Cloud Run has been fantastic.

I had a worker service running on Heroku. Very CPU intensive. The traffic pattern was extremely low throughout the day, but had completely unexpected surges.

On Heroku, my choices were: Paying $3k (basically paying for peak surge throughout the month) or having a lot of slow/failed responses during the surge.

Moved to Cloud Run very easily. Just a normal dockerized 12 factor app.

Now I pay ~$50/m and it automatically scales up when I need more workers.

If you want a managed app platform, it couldn't be more simple and cheap.

The scaling model of Cloud Run has been great. Now that they support websockets, I will be moving all my apps slowly to it.

My only gripe: I wish they had something for worker processes. I know that the rest of Google Cloud has solutions for it but being able to just spawn worker processes as part of the same deployment would be fantastic.

View on HN

Re: worker processes

Have a look at GCP EventArc. It's a new way to trigger cloud run instances. You could create an EventArc trigger that wakes up a worker image, or some such. Basically,EventArc enables serverless event driven design across all GCP. https://cloudblog.withgoogle.com/topics/developers-practitio...

> I wish they had something for worker processes

It may not fit your needs, but did you know that you can invoke other Cloud Run containers from a Cloud Run container?

Alternatively, you can enqueue Cloud Tasks from a Cloud Run container. Those Cloud Tasks can in turn invoke Cloud Run containers.

Not sure if they fit your usecase, but I use both of these approaches and they really expand the capabilities of Cloud Run for me.

How do you differentiate background and worker processes? I’m currently running VMs for background processes processing pub sub topics. Is that not something that could go on cloud run?

When an instance isn't handling a request it either gets killed almost immediately, or if even if you have min idle instances configured, its CPU get's throttled to nothing. So you can't have goroutines or some such doing anything outside of the request context. It's my team's one gripe with Cloud Run. It'd be great to have an option for long-lived instances.

You can set minimum instances now ( well - currently Preview). https://cloud.google.com/run/docs/configuring/min-instances

Like I said, even if the instance is "alive", if it's not currently handling a request it's CPU is throttled to nothing so you can't trust any background process will finish its work.

You can use an HTTP push subscription to an IAM protected Cloud Run service.

How quick does it spin up?

In my case since its background workers, I don't mind the slow startup and I never measured it. Sorry couldn't be more helpful.

My Go-based containers start in much less than a second. I believe its dozens to maybe low hundreds of milliseconds

Depends on the size of the docker image too, we have one with libreoffice (for generating PDFs, invoices, contracts), it takes almost 3 seconds to start at 550MB

Reply on news.ycombinator.com