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

21–30 of 141 posts

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

#21

Post by asciimike »

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?

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

#22

Post by twa927 »

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!

Does max. RAM usage need to be specified upfront, or what's billed is the live-allocated amount?

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

#23

Post by mikehelmick »

twa927 wrote: post #22
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!

Does max. RAM usage need to be specified upfront, or what's billed is the live-allocated amount?

Yes, it needs to be specified upfront.

The default is 128M and you can specify up to 2G

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

#24

Post by asciimike »

dstaley wrote: post #20
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 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?

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

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

#25

Post by [deleted] »

rcconf wrote: post #10
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!

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?

[deleted]

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

#26

Post by scarmig »

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?

"First generation"? Archetypal?

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

#27

Post by mikehelmick »

dstaley wrote: post #20
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 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?

Cloud Functions only supports single concurrency, one request per instance at a time.

Cloud Run supports multi concurrency by default. You might see some benefit due to that difference (fewer cold starts, less CPU time allocated)

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

#28

Post by asciimike »

twa927 wrote: post #22
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!

Does max. RAM usage need to be specified upfront, or what's billed is the live-allocated amount?

"You are billed only for the CPU and memory allocated while a request is active on a container instance, rounded up to the nearest 100 milliseconds."

https://cloud.google.com/run/pricing

You can configure the amount allocated: https://cloud.google.com/run/docs/configuring/memory-limits

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

#29

Post by dstaley »

asciimike wrote: post #24
dstaley wrote: post #20

Earlier quoted context omitted.

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?

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 milliseconds for Cloud Functions.

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

#30

Post by luhn »

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…

I think "the entire time this thing has existed" is plenty long.
Post reply on HN