Live data from Hacker News

Cloud Run – Newest member of our serverless compute stack

cloud.google.com

51–60 of 141 posts

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

#51
post #33
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?

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 the Fargate service down to zero) but I think the cold start times for a Fargate container would be prohibitive--maybe it gets better once you've already scaled up, but in my exploration I've seen Fargate take 45-70 seconds to run a new container. I suspect this is due to Fargate running in your VPC and therefore probably requiring a network interface to be created before the container can be ready.

The exciting part of Cloud Run for me is not that I don't have to manage a Kubernetes cluster, but that I don't have to pay for it when my service is sitting idle.

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

#52
post #48

Earlier quoted context omitted.

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

Ah, thanks for the details there! So, given that my Cloud Functions project is a Go app (and would be the exact same code between Functions and Run), if I were to run that in a very minimal container (something like Alpine), I could get roughly the same cold start time as Cloud Functions, but fewer of them since I can respond to multiple requests using the same instance. I'll probably do some experimentation on my en…

I think you can force cold starts between your tests by re-deploying your function/container. You could (optionally) leave a small buffer (<1 minute) after the deployment to ensure that traffic has fully migrated.

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

#53
post #49

Is there support or integration for the new GCP web application firewall/security product?

I might have missed a product announcement today, but is this Cloud Armor (https://cloud.google.com/armor/)?

If so, no, though we're working on supporting Cloud Armor, CDN, Load Balancing, etc.

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

#54
post #37

What does "Cloud Run on Google Kubernetes Engine" mean? Is there anything beyond the idea that a plain docker container can run on Cloud Run or on GKE?

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 Stackdriver integration for logging, monitoring, and metrics. You also get the Cloud Run UI and CLI to deploy, manage, and update your services.

One of our core goals with Cloud Run is to enable serverless portability; not just for workloads, but tooling and developer experiences. By offering Cloud Run in both a hosted and Kubernetes platform, both enabled by Knative, you can leverage compatible serverless tooling and knowledge across the range of platforms from hosted to GKE to k8s anywhere.

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

#55

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!

Hi Mike, this looks great. I took it for a test-drive with some OpenFaaS functions. https://www.openfaas.com/blog/openfaas-cloudrun/

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

#56
post #37

What does "Cloud Run on Google Kubernetes Engine" mean? Is there anything beyond the idea that a plain docker container can run on Cloud Run or on GKE?

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…

Thanks!

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

#57
post #33
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?

No. Lambda charges you only for when your application is actually handling request (or other events). That isn't an option with Fargate.

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

#58

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!

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?

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

#59
post #49

Is there support or integration for the new GCP web application firewall/security product?

I might have missed a product announcement today, but is this Cloud Armor ( https://cloud.google.com/armor/ )? If so, no, though we're working on supporting Cloud Armor, CDN, Load Balancing, etc.

Yes, thanks, Cloud Armor is what I meant.

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

#60
post #48

Earlier quoted context omitted.

Ah, thanks for the details there! So, given that my Cloud Functions project is a Go app (and would be the exact same code between Functions and Run), if I were to run that in a very minimal container (something like Alpine), I could get roughly the same cold start time as Cloud Functions, but fewer of them since I can respond to multiple requests using the same instance. I'll probably do some experimentation on my en…

I think you can force cold starts between your tests by re-deploying your function/container. You could (optionally) leave a small buffer (<1 minute) after the deployment to ensure that traffic has fully migrated.

Yes on both accounts.
Post reply on HN