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

131–140 of 141 posts

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

#131

Post by chrisbroadfoot »

twa927 wrote: post #75
crashedsnow wrote: post #70

Earlier quoted context omitted.

Memory is a difficult one, especially in garbage-collected languages which have a habit of filling up the heap even when it's not used, so it's not always obvious how much memory is actually being used without having language/runtime specific signals. The mitigation in Cloud Run is both concurrency, and that you're only billed while a request is active. (Disclosure: Google Cloud PM)

> Memory is a difficult one, especially in garbage-collected languages which have a habit of filling up the heap even when it's not used, so it's not always obvious how much memory is actually being used without having language/runtime specific signals. I'm not sure what do you mean here, Cloud Run uses Docker which runs regular processes in a cgroup, so it's sufficient to check the cgroup memory usage, right? Yes, J…

> Cloud Run uses Docker which runs regular processes in a cgroup, so it's sufficient to check the cgroup memory usage, right?

Cloud Run uses gVisor as its container runtime.

Disclaimer: I work on GCP but not much on/with Cloud Run.

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

#132

Post by chrisbroadfoot »

chupasaurus wrote: post #102
twa927 wrote: post #75

Earlier quoted context omitted.

> Memory is a difficult one, especially in garbage-collected languages which have a habit of filling up the heap even when it's not used, so it's not always obvious how much memory is actually being used without having language/runtime specific signals. I'm not sure what do you mean here, Cloud Run uses Docker which runs regular processes in a cgroup, so it's sufficient to check the cgroup memory usage, right? Yes, J…

Cloud Run is built upon Knative so it runs inside k8s (which uses CRI API of a backend, Docker or any other alternative) which handles OOM by inner resource manager, not cgroups.

You can use Cloud Run with GCP-managed infrastructure, and also inside your own GKE cluster.

The GCP-managed infrastructure exposes the Knative API, but doesn't actually run in GKE/k8s.

(I work on GCP but not much/on Cloud Run. Above is correct to my knowledge, but I'm not an expert.)

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

#133

Post by chupasaurus »

chrisbroadfoot wrote: post #132
chupasaurus wrote: post #102

Earlier quoted context omitted.

Cloud Run is built upon Knative so it runs inside k8s (which uses CRI API of a backend, Docker or any other alternative) which handles OOM by inner resource manager, not cgroups.

You can use Cloud Run with GCP-managed infrastructure, and also inside your own GKE cluster. The GCP-managed infrastructure exposes the Knative API, but doesn't actually run in GKE/k8s. (I work on GCP but not much/on Cloud Run. Above is correct to my knowledge, but I'm not an expert.)

Good to know, thank you.

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

#134

Post by jacques_chester »

etaioinshrdlu wrote: post #127
steren wrote: post #122

Earlier quoted context omitted.

For 64 cores, I recommend leveraging custom machine types with Cloud Run on GKE. We are working on more CPU sizes for Cloud Run, but not in a near future for more than 2 vCPUs.

But users want the per-second billing and fast cold start times too. I understand this is kind of a hard CS problem and is basically rooted in needing to move a lot of data around very quickly, all while making the software low latency as well. But solving these is kind of the point of a FaaS. Otherwise we could just run containers on VMs and autoscale ourselves. With terrible cost and cold start times. Maybe look at…

Pooling already happens, AFAIK. On AWS at least you have to pay extra to not be pooled with other customers (ie. for exclusive use of a physical machine, regardless of your VM type).

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

#135

Post by wisswazz »

asciimike wrote: post #113
wisswazz wrote: post #101

Earlier quoted context omitted.

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

Gotcha! So, things like adding Knative eventing which uses serving should be fine while using Cloud Run?

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

#136

Post by charltoons »

asciimike wrote: post #84
charltoons wrote: post #72

Earlier quoted context omitted.

No gRPC support means no server-side Firebase integration, right?

We don't support inbound gRPC/streaming, but we do support outbound gRPC/streaming, so things like Firestore (or other streaming gRPC products) will work fine.

Oh, nice. Thanks for the clarification.

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

#137

Post by jpatokal »

euph0ria wrote: post #129
jpatokal wrote: post #99

Earlier quoted context omitted.

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…

I believe you are incorrect: https://cloud.google.com/support/ states $250/month/user. Hence, it seems to be tied to a single contact person, why else would it state pricing per user? Regarding suspension, if this is the case, why do we see so many desperate cries for help from people whom are unable to get in touch with anyone at all at Google to help them with their termination? They have to resort to public blog p…

Ah, I see what you mean: that's referring to users on the customer's side, not Google's. You also can adjust the number & role of users on the fly, so you can create another production support user if somebody else needs to file a ticket urgently.

From what I've seen, the stories about people having trouble tend to be from Android app developers getting blocked from the Play Store, not GCP users.

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

#138

Post by ryan_partym »

hisnameisjimmy wrote: post #108
euph0ria wrote: post #64

To Google people, do you have any suggestions for startups how to start using your services for production workloads and: 1) Not having to take the $250 monthly fee per dev that needs to be able to contact you. Just increases the start cost massively for your services. 2) Not having to worry about being hell-banned and not being able to restore your account with Google, such as "guilty-by-association" for devs in Pla…

Hell-banning is by far my biggest fear with Google. The idea that you could be banned for life without any explanation just seems completely insane. It feels dystopian.

A couple of direct recommendations to combat this fear.

1. Sales teams can help here. You have a sales rep that you should meet/interact with so that if something like were to happen, you have a person you can reach out to. There has been a lot of news about hiring within sales.

2. Set up a proper Cloud Identity domain and organization. Manage users this way as opposed to consumer accounts.

3. Set up an invoiced billing account

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

#139

Post by ryan_partym »

euph0ria wrote: post #64

To Google people, do you have any suggestions for startups how to start using your services for production workloads and: 1) Not having to take the $250 monthly fee per dev that needs to be able to contact you. Just increases the start cost massively for your services. 2) Not having to worry about being hell-banned and not being able to restore your account with Google, such as "guilty-by-association" for devs in Pla…

I responded further down but on point 2:

A couple of direct recommendations to combat the fear of being banned.

1. Sales teams can help here. You have a sales rep that you should meet/interact with so that if something like were to happen, you have a person you can reach out to. There has been a lot of news about hiring within sales.

2. Set up a proper Cloud Identity domain and organization. Manage users this way as opposed to consumer accounts.

3. Set up an invoiced billing account

Post reply on HN