We at Cloudrun [0] are excited to try Cloud Run for scaling our platform! :) [0] https://cloudrun.co/
While listening to Cloud Run on Spotify https://open.spotify.com/artist/4gCabDwZ2AdhrBYYWQT9t2?si=tL...
Cloud Run – Newest member of our serverless compute stack
121–130 of 141 posts
Re: Cloud Run – Newest member of our serverless compute stack
#122It would be really really amazing if it allowed a large number of CPU cores. Like 64 cores. That would make it interesting for ML inference workloads.
For 64 cores, I recommend leveraging custom machine types with Cloud Run on GKE.
We are working on more CPU sizes for Cloud Run, but not in a near future for more than 2 vCPUs.
Re: Cloud Run – Newest member of our serverless compute stack
#123I have so many batch jobs that run on GCE. Can I run some of them on Cloud Run? I can only run HTTP services now. My use case is very similar to AWS batch. Currently, I use GCE with create-with-container and Cloud scheduler to manage batch loads.
Cloud Scheduler can trigger a Cloud Run service. And this Cloud Run service can run anything, including bash scripts. Take a look at the "Shell" tab in https://cloud.google.com/run/docs/quickstarts/build-and-depl...
Re: Cloud Run – Newest member of our serverless compute stack
#124Hey 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!
Can you compare Google Run to App Engine Flex? They sound similar.
Re: Cloud Run – Newest member of our serverless compute stack
#125Earlier quoted context omitted.
OK thanks! How about persisting files (which actually isn't possible on Heroku but we would like to persist files on disk for simplicity so are debating about just using AWS)?
We provide an in-memory writable filesystem (e.g. you want to do file transformations) but it's not persistent across all instances. We're looking into Filestore integration for a mountable NFS product, though as mentioned in another comment about that, reading is easy but writing is hard.
Why is writing hard? We already use Filestore across multiple VMs in read-write mode. We ensure that writes are unique i.e no two machines will use the same filename. There are also no file modifications.
Re: Cloud Run – Newest member of our serverless compute stack
#126Earlier quoted context omitted.
Thanks, however, it seems limited to 12 months only, which is usually the initial prototyping phase of a product prior to launching. Also, feels strange to have to be in some type of program and beg for mercy with a contact person in order to alleviate the extremely strange behavior of permanent cancellation by algorithms. What if the contact person we have gotten to know have moved on to a different business etc? Fe…
I can understand the concern about getting your account banned, but: if after 12 months, your startup can't afford $250/month for support, you probably have bigger problems. To put it another way: do you think the level of support that Google would be able to provide is less valuable than a few percent of an engineer's salary?
That categorization dismisses a host of evenings & weekend part time bootstrapping startups.
Re: Cloud Run – Newest member of our serverless compute stack
#127It would be really really amazing if it allowed a large number of CPU cores. Like 64 cores. That would make it interesting for ML inference workloads.
For 64 cores, I recommend leveraging custom machine types with Cloud Run on GKE. We are working on more CPU sizes for Cloud Run, but not in a near future for more than 2 vCPUs.
But users want the per-second billing and fast cold start times too.
I understand this is kind of a hard CS problem and is basically rooted in needing to move a lot of data around very quickly, all while making the software low latency as well.
But solving these is kind of the point of a FaaS.
Otherwise we could just run containers on VMs and autoscale ourselves. With terrible cost and cold start times.
Maybe look at how Jelastic does it for a unique take on this. https://jelastic.com/public-cloud-pricing/
This is probably the model that would make users the happiest.
Having poked a bit at how Jelastic does it, it seems they drop a pool of users on a 32-core machine and load balance the users containers with live migration to less utilized machines.
Imagine GCP doing something similar. Drop a big pool of users onto 96 vCPU instances. If an instance starts to get overutilized, live migrate some user containers to a new instance.
Same type of thinking that is probably behind AWS Lambda: how do you satisfy bursty workloads for a lot of users cost effectively? Pool the users. Assume they won't all burst at once.
That has got to be one of the biggest benefits to large public cloud computing.
Re: Cloud Run – Newest member of our serverless compute stack
#128Earlier quoted context omitted.
Thanks, however, it seems limited to 12 months only, which is usually the initial prototyping phase of a product prior to launching. Also, feels strange to have to be in some type of program and beg for mercy with a contact person in order to alleviate the extremely strange behavior of permanent cancellation by algorithms. What if the contact person we have gotten to know have moved on to a different business etc? Fe…
I can understand the concern about getting your account banned, but: if after 12 months, your startup can't afford $250/month for support, you probably have bigger problems. To put it another way: do you think the level of support that Google would be able to provide is less valuable than a few percent of an engineer's salary?
Google support seems to charge per person, so suppose you are a few persons, ie at least 3 sharing the support then it's $750/month. Also, you are assuming US salaries, when looking at many other countries $250 is upwards 10% of the salary. Google support is valuable, but, going with AWS for example is a lot cheaper. Now, if you are a VC-backed or otherwise funded company, then this is a non-issue, but there are hundreds of thousands of businesses that have a total spend on infra that would be less than the support fee from Google.
Re: Cloud Run – Newest member of our serverless compute stack
#129Earlier quoted context omitted.
Thanks, however, it seems limited to 12 months only, which is usually the initial prototyping phase of a product prior to launching. Also, feels strange to have to be in some type of program and beg for mercy with a contact person in order to alleviate the extremely strange behavior of permanent cancellation by algorithms. What if the contact person we have gotten to know have moved on to a different business etc? Fe…
If you purchase Google production support, with credits or otherwise, it's available 24/7 and not tied to a single "contact person". In addition, billing support (which includes things like being suspended for fraud or abuse) is free, available to all and also 24/7. All these channels are responded to by real live humans who can see what "the algorithm" did and why, and overrule it if need. Disclaimer: I work at GCP…
I believe you are incorrect: https://cloud.google.com/support/ states $250/month/user. Hence, it seems to be tied to a single contact person, why else would it state pricing per user?
Regarding suspension, if this is the case, why do we see so many desperate cries for help from people whom are unable to get in touch with anyone at all at Google to help them with their termination? They have to resort to public blog posts and hope that a good Samaritan at Google comes along, sees them and acts.
They all have the same story, "couldn't get in touch with anyone, "tried to appeal, denied without explanation" and they all had several days if not weeks of downtime.
Re: Cloud Run – Newest member of our serverless compute stack
#130Hey 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!
Can you compare Google Run to App Engine Flex? They sound similar.
Cloud Run uses gVisor for its sandbox, Flex runs your container in a dedicated VM.
Cloud Run has a limit of 80 concurrent requests to a copy of your app. Cloud Run has a limit of 2 GiB for memory.
Flex gives you more flexibility over VM shape (CPU, mem), so is suited better to apps that have a higher load. Flex does not scale to zero.
Cloud Run deployments should be faster (Flex provisions a load balancer for each deployment, which can be slow).
Both support deploying directly from container image.
Disclaimer: I work on GCP but have only worked a tiny bit on/with Cloud Run.