Live data from Hacker News

Cloud Run – Newest member of our serverless compute stack

cloud.google.com

11–20 of 141 posts

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

#11
post #6

Earlier quoted context omitted.

Streaming HTTP and gRPC support is on our roadmap, but it's still a ways out :( On the comment about how the control plane APIs support gRPC: the serving infrastructure for the data plane is pretty different from the control plane, so it's unfortunately not a direct map to supporting gRPC on the data plane. Another possible solution is to run an API gateway that does gRPC to JSON conversion and have that invoke your…

Unary gRPC calls would cover all of my uses cases that would benefit from this product. Is that any closer on the roadmap?

My understanding is that the major issue we have is with streaming (sticky sessions to backends that are autoscaling is tricky), so I assume that unary would be easier. I admit that I haven't dived too deeply in to this though.

EDIT: looks like we could do unary gRPC if gRPC wasn't only supported on HTTP/2. So the current implementation basically requires we solve sticky sessions/streaming.

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

#12

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!

Is knative build api supported as well?

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

#13
post #10

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!

Hello, I had a question about how Cloud Run handles security between containers being run on the cloud. I assume my container runs alongside other containers on the same host, how do you prevent privilege escalation exploits?

Cloud Run engineer here.

Containers are run in gVisor https://github.com/google/gvisor as the container sandbox.

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

#14
I'm so excited about the App Engine updates. I'll be signing up for the Ruby 2.5 run time to replace Heroku in our stack.

> Today, we are announcing support for new second generation runtimes: Node.js 10, Go 1.11, and PHP 7.2 in general availability and Ruby 2.5 and Java 11 in alpha. These runtimes provide an idiomatic developer experience, faster deployments, remove previous API restrictions and come with support for native modules. The above-mentioned Serverless VPC access also lets you connect to your existing GCP resources from your App Engine apps in a more secure manner without exposing them to the internet.

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

#15
post #12

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!

Is knative build api supported as well?

No, we don't currently support the Knative Build API.

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

#17
post #10

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!

Hello, I had a question about how Cloud Run handles security between containers being run on the cloud. I assume my container runs alongside other containers on the same host, how do you prevent privilege escalation exploits?

Cloud Run prevents privilege escalation by using gVisor as sandbox technology. Each container has its own isolated user-space kernel from the host.

(Disclaimer: I am Cloud Run dev)

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

#18
post #12

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!

Is knative build api supported as well?

My understanding is that we're working on having Cloud Build support Tekton [1,2] (which is where the Knative Build API now lives)

[1] https://tekton.dev/ [2] https://cloud.google.com/tekton/

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

#19
post #7

Thanks Google cloud team this looks really great. Quick question: Is Cloud Run a zonal or regional resource and is there any way to put this behind the global load balancer? Thanks.

It's regional (and currently only in `us-central1`, though more regions are on the way). We're working on GCLB integration.

Great good to know. Thanks.

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

#20

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 about to launch an API that uses Cloud Functions for the entire app (it's a pretty simple API anyway). I know that Cloud Run gives me more features (being based on containers and all), but given that my API already runs on Cloud Functions, would I get any performance benefits by moving to Cloud Run?
Post reply on HN