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

31–40 of 141 posts

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

#31

Post by asciimike »

wasd wrote: post #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 fo…

Posting here as well in case folks aren't reading the other thread: https://cloud.withgoogle.com/next/sf/sessions?session=SVR209

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

#32

Post by lima »

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?

There's a whole section on "Enabling portability with Knative" and even though I only skimmed the page, I got the message that this is an open standard just like Kubernetes.

As for running regular Docker/OCI containers, I would put more emphasis on how awesome this is for developers:

It's just regular HTTP in Docker containers. You can debug and develop this locally without mocking anything, and it's the same code that runs in production!

And it's all open source. No need to install a Lambda emulator that is almost, but not quite, like the real thing.

I never even considered using AWS Lambda due to the lock in and how annoying it is to work with, but this is something I'll evaluate (by trying it on my local k8s cluster).

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

#33

Post by aksx »

helper wrote: post #16

From a developer perspective, deploying a docker container with a plain http server is much more appealing than the hoops you have to jump through to use the lambda custom runtime stuff. I hope this gets AWS to provide a docker on lambda option.

> AWS to provide a docker on lambda option

isn't that AWS Fargate?

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

#34

Post by hamandcheese »

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 cloud run have the same, better, or worse cold start latency compared to cloud functions?

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

#36

Post by twa927 »

asciimike wrote: post #28
twa927 wrote: post #22

Earlier quoted context omitted.

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

Ok thanks. I'm looking for a way to run a service with memory peaks - 50pct is 200MB and 99pct is 2GB. It looks like no current serverless solution would handle it without overpaying by allocating 2GB for all executions.

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

#38

Post by stewart27 »

dstaley wrote: post #29
asciimike wrote: post #24

Earlier quoted context omitted.

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

Cloud Functions PM here.

Your intuition around concurrency is correct: Cloud Functions has "per instance concurrency" of 1. Cloud Run lets you go significantly higher than that (default 80). This means that our infrastructure will generally create more instances to handle a request spike when using Cloud Functions vs. Cloud Run.

Creating an instance incurs a cold start. Part of that cold start is due to our infrastructure (generally this is small) but the other part is in your control. For example: if you create a client that takes X seconds to you initialize, your cold start will be at least X seconds. The initialization time will manifest as part of your cold start.

This has a few practical implications:

* writing code for Cloud Functions is generally more straightforward as single concurrency solves many problems regarding shared variables. You may also see some benefits in terms of monitoring/metrics/logging since you only need to think about one request at a time.

* you will likely see a higher incidence of cold starts on Cloud Functions during rapid scale-up, such as in response to a sudden traffic spike

* the impact of a given cold start will depend heavily on what you're doing in your container

* though I haven't validated this experimentally, I would expect that the magnitude of any given cold start (i.e., total latency contribution) would be roughly the same on Cloud Run as Cloud Functions IF you're running the same code

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

#39

Post by meeks »

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!

Any chance there will be cron jobs for functions? Right now, I'm using AppEngine just to schedule a function to run.

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

#40

Post by asciimike »

hamandcheese wrote: post #34
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 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, since you can go multi-concurrent in Run, you'll likely see better performance, especially when scaling up.

A nice side effect of this is that your costs will also drop, since you can pack more requests into your instance.

Edit: as noted in the other thread, because you control the container image, you can optimize that (e.g. use Alpine instead of Ubuntu) to reduce weight and decrease cold start time. But if you're using a language like Java, it's possible that starting the JVM and framework is going to be more expensive than the OS load time, so it might be a wash.

Post reply on HN