4 ms·

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 mo

• etaioinshrdlu 8y ago
  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/ 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.
  • jacques_chester 8y ago
    Pooling already happens, AFAIK. On AWS at least you have to pay extra to not be pooled with other customers (ie. for exclusive use of a physical machine, regardless of your VM type).