Does this open the door to having websockets on cloud run?
Cloud Run adds min instances feature for latency-sensitive apps
41–50 of 65 posts
Re: Cloud Run adds min instances feature for latency-sensitive apps
#42Re: Cloud Run adds min instances feature for latency-sensitive apps
#43So if there's something always running .... isn't the same as having on always on server (with auto scaling of some sort)?
When a container is kept warm via " min-instances" but is not receiving requests ("idle"), its CPU costs 10x less than when it's actively processing requests, see pricing: https://cloud.google.com/run/pricing
I don't see the pricing for idle billable time disclosed on that site, only an indication that there is pricing. Am I missing it, or alternatively, could it be clarified?
Re: Cloud Run adds min instances feature for latency-sensitive apps
#44Earlier quoted context omitted.
Worse than that. Its AppEngine Standard vs AppEngine Flex vs Cloud Functions vs Cloud Run vs KNative (Cloud Run, but different). Oh and if you used AppEngine Standard, you can't move to Flex as Flex came with a whole new set of libraries. And Flex to CloudRun didn't exactly have a seamless migration. Along the way they changed multiple internals with deprecation causing code base changes. Such-as Memecache, ImageAPI,…
Everything above. Friends don't let friends use App Engine, and by extension, fringe GCloud services they could break or shitcan at literally any moment The technology of a vendor is way less important than its culture. So far Gcloud seems to understand that. Maybe the App Engine team is outside that org
> Everything above. Friends don't let friends use App Engine, and by extension, fringe GCloud services they could break or shitcan at literally any moment
Not sure why you think they can shitcan them at literally any moment. Although GCP's track record of deprecation is of course far worse than AWS's, they do make and adhere to promises in their terms of service that, in most cases, they will give at least 12 months before deprecating services which have reached general availability. This includes both App Engine and Cloud Run, minus any features that have not yet reached general availability and minus one very fair documented exception for App Engine.
Details:
https://cloud.google.com/terms/deprecation
https://cloud.google.com/terms Disclosure: I used to work for Google, including the GCP team, but I haven't worked for Google in over 5 years and am not speaking for Google here.
Re: Cloud Run adds min instances feature for latency-sensitive apps
#45So if there's something always running .... isn't the same as having on always on server (with auto scaling of some sort)?
It seems they want to replace their managed AppEngine service through Cloud Run in the long run.
This definitely appears to be their trajectory.
One would assume transition from AppEngine to Cloud Run would be directed by establishing a pricing differential that incentivises moving off AppEngine.
Re: Cloud Run adds min instances feature for latency-sensitive apps
#46My god, we are reinventing FastCGI again.
Cloud run can execute multiple requests against the same container at the same time.
With the FaatCGI paradigm, you have to spin up separate process per simultaneous request.
Re: Cloud Run adds min instances feature for latency-sensitive apps
#47Earlier quoted context omitted.
Everything above. Friends don't let friends use App Engine, and by extension, fringe GCloud services they could break or shitcan at literally any moment The technology of a vendor is way less important than its culture. So far Gcloud seems to understand that. Maybe the App Engine team is outside that org
> Everything above. Friends don't let friends use App Engine, and by extension, fringe GCloud services they could break or shitcan at literally any moment Not sure why you think they can shitcan them at literally any moment. Although GCP's track record of deprecation is of course far worse than AWS's, they do make and adhere to promises in their terms of service that, in most cases, they will give at least 12 months…
That’s false. The policy only covers services being turned down. A-la Google reader style. Not api changes. Not forced sdk/software upgrades. Or pricing changes.
Re: Cloud Run adds min instances feature for latency-sensitive apps
#48Yesssss. Right now I have a cron that hits my app every minute to keep it warm. However even with that I see cold starts every now and then. This removed that problem.
It’s so surprising that AWS and Azure don’t have an equivalent to GCP cloud run.
Being able to run a container on demand with a custom image with whatever language and dependencies you want is amazing.
I’ve spun up browsers for snapshotting and seeing a page like a real browser. Cloud run scale from 0 is absolutely magical.
This is what serverless ought to be. Cloud run + firestore makes it possible to build pretty scalable apps with little effort and pretty cheap to run.
Re: Cloud Run adds min instances feature for latency-sensitive apps
#49Compared to AWS, the big thing cloud run and cloud functions are missing is per millisecond billing. Per 100ms billing is too wide grained. AWS lambda has per ms billing and it makes a big difference if your using a perf optimized language like golang or rust.
Re: Cloud Run adds min instances feature for latency-sensitive apps
#50My god, we are reinventing FastCGI again.
Cloud run can execute multiple requests against the same container at the same time. With the FaatCGI paradigm, you have to spin up separate process per simultaneous request.
That's how CGI works, but FastCGI has no such restriction, at least not inherently.
Web server implementations may vary, but Apache at least allows sending many concurrent requests to a single FastCGI backend process: http://httpd.apache.org/docs/trunk/mod/mod_proxy_fcgi.html