7 ms·
Cloud Run adds min instances feature for latency-sensitive apps
- speedgoose 6y agoJust curious but not enough to read the documentation, is there a max setting or can I easily bankrupt my competitors with Apache bench running on a raspberry pi?
- minimaxir 6y agoThere's both a max number of containers setting and a max concurrency limit per container setting. FWIW, I do wish Google added some way to more explicitly prevent abuse with the containers. I had to take down my Cloud Run containers because people found ways to automate access to my services without rate limits, and Google's solution to that was to use a proxy which sorta defeats the point of using Cloud Run.
- renewiltord 6y agoApigee is just such a heavy-weight thing. It feels like API Gateway plus Lambda w/ Containers will provide what you want, though, serverless and easy to set up. You can rate-limit per "usage plan" etc.
- jacques_chester 6y agoSince each instance can handle multiple requests, it might be hard to bankrupt someone with a low-powered box. There's also a standard quota limit for replicas: 1,000 per Service. https://cloud.google.com/run/quotas https://cloud.google.com/run/quotas
- netcyrax 6y agoSo if there's something always running .... isn't the same as having on always on server (with auto scaling of some sort)?
- shishy 6y agoYes but still marginally easier to get it up and running
- davidspiess 6y agoIt seems they want to replace their managed AppEngine service through Cloud Run in the long run.
- justicezyx 6y agoCloud run is developed by the same team that built AppEngine. They share the same technical leadership and a lot of the technical stacks, for example, billing and security (gVisor). I dont think it's that simple to replace one service with another. It requires a lot of very sensitive dealing with external customers. And one cannot (easily) use the typical "Google deprecation" on a Cloud service offering, either. So it's complicated. But your impression is not too far from the inclination.
- nojvek 6y agoI’d imagine google would at-least make both appEngine run on the same core primitives that cloud run uses. So while the public facing api is the same, the internals are replaced. At-least that’s how I’d approach it. Deprecate app-engine in that it will be infinitely supported until the last customer, but all new stuff is advocated to be used on cloud run.
- zadokshi 6y agoThis 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.
- steren 6y agoWhen 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 https://cloud.google.com/run/pricing
- jpochtar 6y agoDoes this apply to Firebase functions as well?
- cocktailpeanuts 6y agoI wonder how this compares to Cloudflare Workers Unbound https://blog.cloudflare.com/introducing-workers-unbound/ https://blog.cloudflare.com/introducing-workers-unbound/
- nojvek 6y agoCloudflare workers both bundled and unbound run on v8 isolates. While they’re performant you can only use JavaScript. Js that works with cloudflare’s v8 version. With google cloud run it’s effectively running your container. You can use whatever language you want, whatever apt dependencies you need, whatever Linux flavor (ubuntu/alpine/busybox) e.t.c In that sense cloud run is the more generic serverless platform. The devs can indeed say “it works on my machine, so let’s ship my machine and scale it up as needed and hibernate when not in use”
- ditonal 6y agoAppEngine has had scale-to-zero for 15 years, but instead of having a coherent product strategy, why not just launch a different competing product every year which is missing features that already exist? AppEngine vs Cloud Functions vs Cloud Run, the reasons these all exist at the same time is not because it makes any sense for customers, but because Google PMs get promoted for launching new things rather than supporting existing products.
- Axsuul 6y agoI disagree. App Engine is nothing like Cloud Functions/Run. The former is a better fit for your entire app stack (think Heroku) while the latter is for ad-hoc. As for Cloud Functions and Cloud Run, the way you deploy is completely different. Cloud Run is strictly meant for containers.
- mayank 6y agoI don't think the 3 products are serving as diverse a set of use cases as you think... > The former is a better fit for your entire app stack (think Heroku) while the latter is for ad-hoc. There's no product reason why App Engine couldn't start deploying custom containers. > As for Cloud Functions and Cloud Run, the way you deploy is completely different. Cloud Run is strictly meant for containers. AWS Lambda (arguably the "inspiration" for Cloud Functions) just announced support for custom containers. Cloud Functions could too. And then you essentially have Cloud Run.
- hn_throwaway_99 6y ago> There's no product reason why App Engine couldn't start deploying custom containers. There better not be because it already does: https://cloud.google.com/appengine/docs/flexible/custom-runtimes https://cloud.google.com/appengine/docs/flexible/custom-runt...
- ditonal 6y agoActually, App Engine is a LOT like Cloud Functions/Run. You have some code that you want to run in the Cloud and you don't want to worry about server ops. Whether that's your "whole stack" or something "ad-hoc" is a totally arbitrary distinction. Your "whole stack" will almost certainly involve external concerns, and your "ad-hoc" concerns will almost certainly grow in complexity until they converge on the same spot. AppEngine is also running containers via gvisor. The distinction is being driven by PMs and marketers but not by the needs of customers. What end-users need is one well-supported tool, not 8 separate tools with uncertainty about which one will receive future support and matrices and flowcharts to decide between them.
- mrgleeco 6y agoWondering where this magic lives in the stack. Is this possible in Knative? Just elaborate ctl-Z?
- jacques_chester 6y ago> Is this possible in Knative? Yes: https://knative.dev/docs/serving/autoscaling/scale-bounds/#upper-bound https://knative.dev/docs/serving/autoscaling/scale-bounds/#u... I also wrote about it: https://livebook.manning.com/book/knative-in-action/chapter-5/v-6/210 https://livebook.manning.com/book/knative-in-action/chapter-...
- melbourne_mat 6y agoThis is probably not a response to the other story this week about a start-up that got a $70k bill from Google cloud erroneously: https://news.ycombinator.com/item?id=25372336 https://news.ycombinator.com/item?id=25372336
- LeviDayne 6y agoHow would a min amount of cloud run processes be a response to a billing issue born from a series of unfortunate events?
- frakkingcylons 6y agoThis feature doesn't cap your costs. It's to reduce/eliminate cold start times for your containers.
- bscanlan 6y agoThis is a response to this AWS Lambda launch, over a year later: https://aws.amazon.com/blogs/compute/new-for-aws-lambda-predictable-start-up-times-with-provisioned-concurrency/ https://aws.amazon.com/blogs/compute/new-for-aws-lambda-pred...
- howlgarnish 6y agoCloud Run is for containers, not functions, and it's the next evolution of App Engine. The GCP equivalent to Lambda is Cloud Functions.
- justicezyx 6y agoDid Cloud Functions launch the equivalent to Lambda launch yet?
- yeldarb 6y agoNo, but would love to see it.
- justicezyx 6y ago``` package main import ( "fmt" "log" "net/http" ) func init() { setupDBConnection(dbName) } func handler(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, "Hi there, I love %s!", r.URL.Path[1:]) } func main() { fmt.Println("Processing your serverless request") http.HandleFunc("/", handler) log.Fatal(http.ListenAndServe(":8080", nil)) } ``` This code snippet is an example of "Run bootstrapping logic once, and reuse it across Min Instances". Assuming the boostrapping logic refers to the `init()` function that connects to DB. Does Cloud Run looks for init() in a Golang app to invoke? I cannot seem follow the code's logic and its connection with the stated purpose. Did I miss anything?
- yegle 6y ago`init()` is part of Golang spec: https://golang.org/ref/spec#Package_initialization https://golang.org/ref/spec#Package_initialization
- madsbuch 6y agoCreate a problem -> Create a solution -> That create a problem -> Create a solution -> That creates a problem -> create a ... The big quesation is how derived we can be of actual value creation before wheels stop spinning...
- stefan_ 6y agoMy god, we are reinventing FastCGI again.
- ec109685 6y agoCloud 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.
- teraflop 6y agoThat'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 http://httpd.apache.org/docs/trunk/mod/mod_proxy_fcgi.html
- intellix 6y agoDoes this open the door to having websockets on cloud run?
- nojvek 6y agoNo cloud run is only for http requests only. Not even push. You want to use this for short lived requests. Web sockets need more persistent connections. Although may be there is a way I don’t know.
- intellix 6y agoIt was a limitation before but maybe not soon (they would have already mentioned it). Knative in your own cluster supports it but I want scale to zero instead of paying for a cluster. They say that it supports sockets but not bi-directional. You can't send messages back up the socket which we're using for GQL mutations
- nojvek 6y agoYesssss. 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.
- deleted 6y ago[deleted]
- jtsiskin 6y agoYeah this setup is the biggest advantage I see to the cloud vs self hosted - the possibility of far more efficient resource usage due to things like cloud run, lambda, etc. I dream of a day when the underlying “cloud” is completely commoditized and interoperable, and your code will run wherever is cheapest, and the cost actually becomes less than self hosting.
- digianarchist 6y agoAWS added container support to Lambda recently.
- nojvek 6y agoIt’s not the same as cloud run though. Cloud run just needs a thing listening on $PORT environment variable. That’s the only interface needed to the container. The rest is totally agnostic to knowing that it’s inside cloud run.
- digianarchist 6y agoAh I see. So there's no need to write an interface that accepts the event object? It's all HTTP on Google Cloud Run? Do you have to gracefully shutdown the container or does Google just kill the container once it gets a response?
- nojvek 6y agoCompared 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.
- deleted 6y ago[deleted]