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

91–100 of 141 posts

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

#91

Post by jmathai »

robrtsql wrote: post #51
aksx wrote: post #33

Earlier quoted context omitted.

> AWS to provide a docker on lambda option isn't that AWS Fargate?

Yes and no--Fargate is a Docker container which runs on an ECS cluster that you don't have to manage, sure, but it doesn't scale down to zero. As far as I know, there's no support for running an HTTP endpoint and then having the container start in response to a request coming in. You could build that yourself (although I suspect it would require running some long-lived infrastructure, defeating the purpose of scaling…

Looks like AWS Faragate pricing is per invocation and duration of tasks.

> Pricing is per second with a 1-minute minimum. Duration is calculated from the time you start to download your container image (docker pull) until the Task terminates, rounded up to the nearest second.

https://aws.amazon.com/fargate/pricing/

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

#92

Post by hn_throwaway_99 »

d_w_b wrote: post #41
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…

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 f…

Thanks very much! Could you answer the following questions about cold start times in Cloud Run or point me to a good resource:

1. I think I have a pretty good understanding of what's going on with the lifecycle of Cloud Functions that leads to the cold start times. What happens with Cloud Run? Does it need to download the whole Docker image to a machine to run it? Seems like that would take longer. 2. App Engine has 'warmup requests', which I think are great. Is there any equivalent on Cloud Run, or plan to add? 3. Is the time that an instance is kept warm during idle similar between Cloud Functions and Cloud Run?

Thanks!

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

#93

Post by hn_throwaway_99 »

asciimike wrote: post #40
hamandcheese wrote: post #34

Earlier quoted context omitted.

Does cloud run have the same, better, or worse cold start latency compared to cloud functions?

Cloud Functions is single concurrency, meaning every new request causes a cold start (generally speaking). Cloud Run can be single or multi-concurrency (defaults to 80), meaning one in 80 requests globally causes a cold start (again, generally speaking, assuming the container isn't CPU bound below that, etc.). So, if both are running in single concurrency mode, you'll likely see similar cold start time; however, sinc…

Sorry, just asked a similar question in response to a different comment, but just saw this detailed response. Do you know if there are any plans to add 'warmup requests' to Cloud Run like in App Engine?

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

#94

Post by hn_throwaway_99 »

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).

Note to Firebase team: I use exactly this (a Cloud Scheduler job that pushes to a pub/sub topic, and then set a Firebase function that runs on a topic trigger) to schedule functions, but would be really nice if I could just create a triggered cron function like this:

functions.cron.schedule('0 0 * * *').onSchedule(...)

or something like that. Even if it behind the scenes it just did exactly what I'm doing manually now, I see so many questions about cron-triggered functions that it would save a ton of people time searching for what the best route is to take.

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

#95

Post by asciimike »

sbr464 wrote: post #90

Can Cloud Run work with GCP Memorystore (managed cache)? Also, one limitation of GCP cloud functions was the ability to communicate directly to a private network VM, although a solution is in beta I think. Does Cloud Run have this limitation?

We'll be adding VPC Connectors to Cloud Run shortly, which will let it talk to Memorystore. As you mentioned, they went Beta for GCF and GAE today.

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

#96

Post by d_w_b »

stewart27 wrote: post #52
dstaley wrote: post #48

Earlier quoted context omitted.

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 en…

I think you can force cold starts between your tests by re-deploying your function/container. You could (optionally) leave a small buffer (<1 minute) after the deployment to ensure that traffic has fully migrated.

I spoke too soon. The deploy will bring up an instance instead of your first request. To force a cold start, you could set concurrency to '1' and send two concurrent requests. You should see a log entry such as the following when a new instance starts up: "This request caused a new container instance to be started and may thus take longer and use more CPU than a typical request." Alternatively, you could set up an endpoint that shuts down the server (which will shut down the instance - not advised for production code).

As an aside, the "K_REVISION" environment variable is set to the current revision. You can log or return this value to test whether traffic has migrated to a new version (instead of waiting a minute).

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

#98

Post by wgoodall01 »

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!

I'm a student, mainly using GCP for hobby/hackathon projects, and to teach myself.

I am massively excited about Cloud Run's free tier---for someone with a budget of zero, being able to get a project off the ground and functional without paying through the nose if you forget to turn down some service is incredibly useful. Getting an unexpected $40 App Engine bill at the end of the month isn't fun.

I'm definitely going to check Cloud Run out as a go-to for future projects--it looks like a really good fit for my use case.

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

#99

Post by jpatokal »

euph0ria wrote: post #79
asciimike wrote: post #66

Earlier quoted context omitted.

Have you reached out to: https://cloud.google.com/developers/startups/ They should be able to give you a pretty large chunk of credit (I assume it'll cover support as well). It should also give you folks to contact and help prevent the latter issue.

Thanks, however, it seems limited to 12 months only, which is usually the initial prototyping phase of a product prior to launching. Also, feels strange to have to be in some type of program and beg for mercy with a contact person in order to alleviate the extremely strange behavior of permanent cancellation by algorithms. What if the contact person we have gotten to know have moved on to a different business etc? Fe…

If you purchase Google production support, with credits or otherwise, it's available 24/7 and not tied to a single "contact person". In addition, billing support (which includes things like being suspended for fraud or abuse) is free, available to all and also 24/7. All these channels are responded to by real live humans who can see what "the algorithm" did and why, and overrule it if need.

Disclaimer: I work at GCP and used to work in support.

Post reply on HN