Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cloud Run – Newest member of our serverless compute stack

cloud.google.com

Post reply on HN
Print view View original

41–50 of 141 posts

Re: Cloud Run – Newest member of our serverless compute stack

#41

Post by d_w_b »

dstaley wrote: post #29
asciimike wrote: post #24

Earlier quoted context omitted.

Does the Cloud Functions solution meet your current performance requirements? If so, don't worry about moving it. The main benefits you'd see immediately are toolchain (e.g. Docker containers, existing build systems, etc.).

I haven't launched it, so I'm not sure about performance. My main concerns are cold starts and concurrency. It's my understanding that Cloud Run has higher concurrency per container instance, so my guess would be that Cloud Run would give me fewer cold starts than Cloud Functions. However, since Cloud Run is a generic runtime, I'd imagine that cold starts there would be on the scale of seconds compared to millisecond…

Disclosure: Cloud Run Engineer

I'd encourage you to test your particular app, but you should expect similar cold start times in Cloud Run.

You can set "Maximum Requests per Container" on container deployment so you are in control whether a container has single concurrency (i.e. "Maximum Requests per Container = 1"). If your app is not CPU-bound and you allow multiple concurrent requests (the default) you should see fewer cold starts.

Re: Cloud Run – Newest member of our serverless compute stack

#42

Post by asciimike »

meeks wrote: post #39
asciimike wrote: post #4

Hey folks, one of the Cloud Run PMs (along with @steren, @ryangregg, @lindydonna, @stewart27, and others). We're super excited to announce Cloud Run and Cloud Run on GKE, both implementing the Knative Serving API. Please let us know if you've got any questions!

Any chance there will be cron jobs for functions? Right now, I'm using AppEngine just to schedule a function to run.

Check out Cloud Scheduler (https://cloud.google.com/scheduler/) which can target an arbitrary HTTP URL, and will support authenticated push to securely target Cloud Functions and Cloud Run (I think this is going to public beta this week).

Re: Cloud Run – Newest member of our serverless compute stack

#44

Post by w-m »

asciimike wrote: post #21
w-m wrote: post #8

"Traditional serverless offerings come with challenges such as constrained runtime support and vendor lock-in. [...]" I'm quite aware that there's a technology hype cycle in web development, quickly replacing last year's fad. But whoever came up with the idea of putting the words `traditional` ("following or belonging to the customs or ways of behaving that have continued in a group of people or society for a long ti…

Five years is a long time in a world where front end frameworks seem to change every six months ;) Kidding aside, how would you suggest we re-phrase this to make it clear that we think that arbitrary Docker containers + conformance to the Knative spec (which you can run anywhere) is a clear differentiator?

I would have been probably less irritated by something simple like "current serverless solutions". But I'm not a web developer and don't understand the differentiation details you mention, so I'm not in the target demographic here.

From my outsider's perspective, serverless is something that just recently came into mainstream usage. People who this product is made for probably see this differently and thus wouldn't have a problem with the formulation.

Language pedantry aside, good luck with your product launch :)

Re: Cloud Run – Newest member of our serverless compute stack

#45

Post by stewart27 »

asciimike wrote: post #42
meeks wrote: post #39

Earlier quoted context omitted.

Any chance there will be cron jobs for functions? Right now, I'm using AppEngine just to schedule a function to run.

Check out Cloud Scheduler ( https://cloud.google.com/scheduler/ ) which can target an arbitrary HTTP URL, and will support authenticated push to securely target Cloud Functions and Cloud Run (I think this is going to public beta this week).

+1

You can also set up Cloud Scheduler to push to Pub/Sub, which can trigger your function. This is helpful if you don't want your function to be available via a public HTTPS endpoint.

Re: Cloud Run – Newest member of our serverless compute stack

#47

Post by asciimike »

helper wrote: post #37

What does "Cloud Run on Google Kubernetes Engine" mean? Is there anything beyond the idea that a plain docker container can run on Cloud Run or on GKE?

It means that we support the same toolchain across Cloud Run (running on our fully managed infrastructure) as well as Cloud Run on GKE (running on your k8s cluster). For example:

``` # deploy to the fully managed product gcloud beta run deploy --image gcr.io/foo/bar --region us-central1

# deploy to a GKE cluster gcloud beta run deploy --image gcr.io/foo/bar --cluster myCluster --cluster_location us-central1-a ```

Cloud Run on GKE specifically adds the Knative CRDs (e.g. Knative Serving) to your GKE cluster, giving you additional autoscaling and different rollout primitives.

Re: Cloud Run – Newest member of our serverless compute stack

#48

Post by dstaley »

stewart27 wrote: post #38
dstaley wrote: post #29

Earlier quoted context omitted.

I haven't launched it, so I'm not sure about performance. My main concerns are cold starts and concurrency. It's my understanding that Cloud Run has higher concurrency per container instance, so my guess would be that Cloud Run would give me fewer cold starts than Cloud Functions. However, since Cloud Run is a generic runtime, I'd imagine that cold starts there would be on the scale of seconds compared to millisecond…

Cloud Functions PM here. Your intuition around concurrency is correct: Cloud Functions has "per instance concurrency" of 1. Cloud Run lets you go significantly higher than that (default 80). This means that our infrastructure will generally create more instances to handle a request spike when using Cloud Functions vs. Cloud Run. Creating an instance incurs a cold start. Part of that cold start is due to our infrastru…

Ah, thanks for the details there! So, given that my Cloud Functions project is a Go app (and would be the exact same code between Functions and Run), if I were to run that in a very minimal container (something like Alpine), I could get roughly the same cold start time as Cloud Functions, but fewer of them since I can respond to multiple requests using the same instance.

I'll probably do some experimentation on my end as well to test. Any suggestion how long I should wait between tests to ensure a cold start on both Cloud Functions and Cloud Run?

Re: Cloud Run – Newest member of our serverless compute stack

#50

Post by asciimike »

sbr464 wrote: post #43

Curious if websockets, sticky sessions are supported?

Not on Cloud Run, though you can do this on Cloud Run on GKE.

There are some interesting billing implications of persistent connections (e.g. we don't know what's going on in that session [if there's traffic or not]), so we'll likely have to bill you the entire time the connection is open.

Post reply on HN