We at Cloudrun [0] are excited to try Cloud Run for scaling our platform! :)
Cloud Run – Newest member of our serverless compute stack
61–70 of 141 posts
Re: Cloud Run – Newest member of our serverless compute stack
#62https://cloud.google.com/run/docs/reference/container-contra...
Details the contract your container must meet to run on the service and limitations you might run into
Quite a nice document to be fair.
Would be interested in hearing what use cases people would use this for, over say Cloud Functions or AWS Lambda. I'd imagine the flexibility of being able to run anything that supports HTTP is quite attractive.
One thing I did spot though is the container instance is limited to one vCPU, I wonder if people will hit performance ceilings? For lambda they abstract the CPU allocated based on the memory tiers, I'm not sure if this is the same though
Re: Cloud Run – Newest member of our serverless compute stack
#63Hey 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?
Yes, there are plans for traffic splitting.
Currently Cloud Run only supports the `runLatest` mode of the Knative Serving spec (https://github.com/knative/serving/blob/master/docs/spec/spe...) but we're working on other modes (e.g. `release`) which would allow for traffic splits.
Re: Cloud Run – Newest member of our serverless compute stack
#64To 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 PlayStore/gApps etc trickling over to closing down the whole account. We have read so many of those stories here on HN lately that I'm terrified to use Google for anything business related as we run the risk of losing everything.
The Cloud Run product looks great and would love to use it but the above two issues makes it a no go for us.
Re: Cloud Run – Newest member of our serverless compute stack
#65Earlier quoted context omitted.
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 infrastru…
[deleted]
Re: Cloud Run – Newest member of our serverless compute stack
#66To 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…
Have you reached out to: https://cloud.google.com/developers/startups/
They should be able to give you a pretty large chunk of credit (I assume it'll cover support as well). It should also give you folks to contact and help prevent the latter issue.
Re: Cloud Run – Newest member of our serverless compute stack
#67Finally a serverless technology that is actually serverless to the developer ($0 when idle).
Re: Cloud Run – Newest member of our serverless compute stack
#68To 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…
GCP Community Slack is a great place to get access to both Googlers and non Googlers using and understanding platform.
Re: Cloud Run – Newest member of our serverless compute stack
#69What 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?
I am so glad somebody asked, 5 sec into the page and I had to Google what this Google is all about. It seems we have new meaning being fitted into the word Cloud and Serverless every 5 months and the page was written by marketing team.
This post [1] explains it a lot better. Quoted from the doc. ( Why they didn't include it in the page is beyond me )
"Cloud Run is a managed compute platform that enables you to run stateless containers that are invocable via HTTP requests. Cloud Run is serverless: it abstracts away all infrastructure management, so you can focus on what matters most — building great applications. It is built from Knative, letting you choose to run your containers either fully managed with Cloud Run, or in your Google Kubernetes Engine cluster with Cloud Run on GKE.". So, like lambda but with containers. Pretty much what I have wanted since I first started learning about Docker.
Re: Cloud Run – Newest member of our serverless compute stack
#70Earlier quoted context omitted.
"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.
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)