Live data from Hacker News

Cloud Run – Newest member of our serverless compute stack

cloud.google.com

111–120 of 141 posts

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

#111
post #58

Earlier quoted context omitted.

Just tried creating a service with the sample image and love the quick deployment time compared to AppEngine Flex. I noticed that the console shows a traffic percentage for each revision, but no apparent way to change it. Any plans to support traffic splitting, or at least a one-click way to re-activate (or re-deploy) an older revision?

When would you use Cloud Run vs App Engine Flex? Doesn't App Engine Flex essentially help you run an app in a container and handle scaling too? For example, what if you're running a stateless JVM app like something on Play Framework. Could you run it on either App Engine Flex or Cloud Run, and if so, what considerations would there be for choosing one over the other?

0. Flex doesn't scale to zero, Run does.

1. Flex runs directly on VMs (sharing some GCE networking, access to GPUs, etc.), Run doesn't.

Those are the two that come up top of mind. We're working on a more comprehensive "choose your compute product" walkthrough in the near future.

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

#112

Earlier quoted context omitted.

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?

Replied there!

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

#113

Earlier quoted context omitted.

Product manager for Cloud Run on GKE here. Cloud Run on GKE brings a managed experience for Knative/serving and Istio that aligns with Cloud Run. We install and manage the Knative version in your cluster and keep it running for you. Above what you get with base Kubernetes ability to deploy a container, Cloud Run on GKE gives you request-based auto-scaling of container instances, network programming with Istio, and St…

Does this mean that by using Cloud Run GKE I can also leverage the primitives provided by Istio and Knative Serving?

Cloud Run on GKE is Knative (which relies on Istio) installed on your GKE cluster, and updated by us. So yes, you can go and muck around with lower level Istio/K8s primitives, but only to a point (there are places where you can break Cloud Run on GKE if you configure things particular ways). Over time we're working on making those actions more clear and ensuring that you get all the benefits of the Istio mesh built in, plus the ability to reconfigure to suit your needs (e.g. adding Istio RBAC like we have with Cloud IAM on Cloud Run).

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

#114
post #46
post #35

Is there info on cold start times for various languages, or configurations? Lambdas, for example, are pretty slow starting if they need connectivity into a VPC, or use Java.

I’m also curious about cold start performance, latency.

Wanted to drop in and say that I've seen this and am looking for any data that we're willing/able to share on our internal benchmarks.

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

#115

Earlier quoted context omitted.

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…

1. Both cases grab the image and run it. Better per-layer caching (including very aggressive caching of common layers) is coming soon, so stay tuned. 2. No current equivalent, though there are thoughts on exposing more scaling control knobs (e.g. max-instances, min-instances). Max is easy, min is harder because of the cost implications. GAE was billed on "instance hours" but Run is CPU time, so if you go "min-instanc…

Just wanted to say thanks to you and the rest of the GCP crew for being all over this thread. Most appreciated!

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

#116

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…

I can understand the concern about getting your account banned, but: if after 12 months, your startup can't afford $250/month for support, you probably have bigger problems.

To put it another way: do you think the level of support that Google would be able to provide is less valuable than a few percent of an engineer's salary?

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

#117
post #91

Earlier quoted context omitted.

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/

A "task" in ECS means a container. In Fargate, in order to be ready to receive requests 24/7, you have to pay to have a container running 24/7. In that sense, it feels a lot closer to EC2 than it does to Lambda.

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

#118
post #39

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.

Cron jobs in knative: https://www.knative.dev/docs/eventing/samples/cronjob-source...

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

#120

Earlier quoted context omitted.

When would you use Cloud Run vs App Engine Flex? Doesn't App Engine Flex essentially help you run an app in a container and handle scaling too? For example, what if you're running a stateless JVM app like something on Play Framework. Could you run it on either App Engine Flex or Cloud Run, and if so, what considerations would there be for choosing one over the other?

0. Flex doesn't scale to zero, Run does. 1. Flex runs directly on VMs (sharing some GCE networking, access to GPUs, etc.), Run doesn't. Those are the two that come up top of mind. We're working on a more comprehensive "choose your compute product" walkthrough in the near future.

Comparison doc in the future would be great!

It sounds like there's a bit of overlap. If I'm not up and running yet and just want the most managed solution (least work to run, with the most powerful high level features), is one of these a clear choice?

In my case, I don't care as much about low level access, but I just want my app to run quickly and efficiently. App Engine Flex's ability to run multiple services within an application, get load balancing set up, have versions of the app for testing and rollbacks, etc seems great. However, overall I just want to the easiest way to run my stateless set of services.

Post reply on HN