7 ms·

Hey 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

Hey 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!

rcconf 8y ago
Hello, I had a question about how Cloud Run handles security between containers being run on the cloud. I assume my container runs alongside other containers on the same host, how do you prevent privilege escalation exploits?
- mikehelmick 8y ago
  Cloud Run engineer here. Containers are run in gVisor https://github.com/google/gvisor https://github.com/google/gvisor as the container sandbox.
- wlhee 8y ago
  Cloud Run prevents privilege escalation by using gVisor as sandbox technology. Each container has its own isolated user-space kernel from the host. (Disclaimer: I am Cloud Run dev)
- deleted 8y ago
  [deleted]
jpdb 8y ago
Is knative build api supported as well?
- mikehelmick 8y ago
  No, we don't currently support the Knative Build API.
- asciimike 8y ago
  My understanding is that we're working on having Cloud Build support Tekton [1,2] (which is where the Knative Build API now lives) [1] https://tekton.dev/ https://tekton.dev/ [2] https://cloud.google.com/tekton/ https://cloud.google.com/tekton/
dstaley 8y ago
I'm about to launch an API that uses Cloud Functions for the entire app (it's a pretty simple API anyway). I know that Cloud Run gives me more features (being based on containers and all), but given that my API already runs on Cloud Functions, would I get any performance benefits by moving to Cloud Run?
- asciimike 8y ago
  Does the Cloud Functions solution meet your current performance requirements? If so, don't worry about moving it. The main benefits you'd see immediately are toolchain (e.g. Docker containers, existing build systems, etc.).
  - dstaley 8y ago
    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 milliseconds for Cloud Functions.
    - stewart27 8y ago
      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 infrastructure (generally this is small) but the other part is in your control. For example: if you create a client that takes X seconds to you initialize, your cold start will be at least X seconds. The initialization time will manifest as part of your cold start. This has a few practical implications: * writing code for Cloud Functions is generally more straightforward as single concurrency solves many problems regarding shared variables. You may also see some benefits in terms of monitoring/metrics/logging since you only need to think about one request at a time. * you will likely see a higher incidence of cold starts on Cloud Functions during rapid scale-up, such as in response to a sudden traffic spike * the impact of a given cold start will depend heavily on what you're doing in your container * though I haven't validated this experimentally, I would expect that the magnitude of any given cold start (i.e., total latency contribution) would be roughly the same on Cloud Run as Cloud Functions IF you're running the same code
twa927 8y ago
Does max. RAM usage need to be specified upfront, or what's billed is the live-allocated amount?
- mikehelmick 8y ago
  Yes, it needs to be specified upfront. The default is 128M and you can specify up to 2G
- asciimike 8y ago
  "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 https://cloud.google.com/run/pricing You can configure the amount allocated: https://cloud.google.com/run/docs/configuring/memory-limits https://cloud.google.com/run/docs/configuring/memory-limits
  - twa927 8y ago
    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.
    - crashedsnow 8y ago
      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)
      - twa927 8y ago
        > 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. I'm not sure what do you mean here, Cloud Run uses Docker which runs regular processes in a cgroup, so it's sufficient to check the cgroup memory usage, right? Yes, Java can always use large heaps but we're running Python and C++ where a process' memory usage directly relates to what a program allocates (even PyPy with GC has this property). > The mitigation in Cloud Run is both concurrency, and that you're only billed while a request is active. When there are memory peaks, larger deployments without container-level concurreny look better. For my example 16GB of RAM allows running 8 containers to get a chance for a 2GB task to complete, but on average 90% of the memory will be wasted. On a single 16GB server I can run 48 tasks with 40% wasted and a high chance of the 2GB tasks finishing. Yes, in this scenario I must handle tasks killed due to OOM but the difference in throughput is so large that it's worth it.
hamandcheese 8y ago
Does cloud run have the same, better, or worse cold start latency compared to cloud functions?
- asciimike 8y ago
  Cloud Functions is single concurrency, meaning every new request causes a cold start (generally speaking). Cloud Run can be single or multi-concurrency (defaults to 80), meaning one in 80 requests globally causes a cold start (again, generally speaking, assuming the container isn't CPU bound below that, etc.). So, if both are running in single concurrency mode, you'll likely see similar cold start time; however, since you can go multi-concurrent in Run, you'll likely see better performance, especially when scaling up. A nice side effect of this is that your costs will also drop, since you can pack more requests into your instance. Edit: as noted in the other thread, because you control the container image, you can optimize that (e.g. use Alpine instead of Ubuntu) to reduce weight and decrease cold start time. But if you're using a language like Java, it's possible that starting the JVM and framework is going to be more expensive than the OS load time, so it might be a wash.
  - hn_throwaway_99 8y ago
    Sorry, just asked a similar question in response to a different comment, but just saw this detailed response. Do you know if there are any plans to add 'warmup requests' to Cloud Run like in App Engine?
    - asciimike 8y ago
      Replied there!
meeks 8y ago
Any chance there will be cron jobs for functions? Right now, I'm using AppEngine just to schedule a function to run.
- asciimike 8y ago
  Check out Cloud Scheduler (https://cloud.google.com/scheduler/ https://cloud.google.com/scheduler/) which can target an arbitrary HTTP URL, and will support authenticated push to securely target Cloud Functions and Cloud Run (I think this is going to public beta this week).
  - stewart27 8y ago
    +1 You can also set up Cloud Scheduler to push to Pub/Sub, which can trigger your function. This is helpful if you don't want your function to be available via a public HTTPS endpoint.
  - hn_throwaway_99 8y ago
    Note to Firebase team: I use exactly this (a Cloud Scheduler job that pushes to a pub/sub topic, and then set a Firebase function that runs on a topic trigger) to schedule functions, but would be really nice if I could just create a triggered cron function like this: functions.cron.schedule('0 0 * * *').onSchedule(...) or something like that. Even if it behind the scenes it just did exactly what I'm doing manually now, I see so many questions about cron-triggered functions that it would save a ton of people time searching for what the best route is to take.
    - asciimike 8y ago
      We are working on this right now, so stay tuned :)
- jganetsk 8y ago
  Cron jobs in knative: https://www.knative.dev/docs/eventing/samples/cronjob-source/ https://www.knative.dev/docs/eventing/samples/cronjob-source...
alexellisuk 8y ago
Hi Mike, this looks great. I took it for a test-drive with some OpenFaaS functions. https://www.openfaas.com/blog/openfaas-cloudrun/ https://www.openfaas.com/blog/openfaas-cloudrun/
lxxvii 8y ago
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?
- asciimike 8y ago
  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/spec.md#service 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.
- crisscrosscrash 8y ago
  When would you use Cloud Run vs App Engine Flex? Doesn't App Engine Flex essentially help you run an app in a container and handle scaling too? For example, what if you're running a stateless JVM app like something on Play Framework. Could you run it on either App Engine Flex or Cloud Run, and if so, what considerations would there be for choosing one over the other?
  - asciimike 8y ago
    0. Flex doesn't scale to zero, Run does. 1. Flex runs directly on VMs (sharing some GCE networking, access to GPUs, etc.), Run doesn't. Those are the two that come up top of mind. We're working on a more comprehensive "choose your compute product" walkthrough in the near future.
    - crisscrosscrash 8y ago
      Comparison doc in the future would be great! It sounds like there's a bit of overlap. If I'm not up and running yet and just want the most managed solution (least work to run, with the most powerful high level features), is one of these a clear choice? In my case, I don't care as much about low level access, but I just want my app to run quickly and efficiently. App Engine Flex's ability to run multiple services within an application, get load balancing set up, have versions of the app for testing and rollbacks, etc seems great. However, overall I just want to the easiest way to run my stateless set of services.
ivanr 8y ago
Can you provide some information about when you might be adding support for IPv6? It's a deal-breaker for our particular use cases.
- mrwilliamchang 8y ago
  Can you clarify what is not working for you? IPv6 should work. (I work on Cloud Run).
  - ivanr 8y ago
    Sorry, my question was about outbound IPv6. At the backend, we need full IPv4 and IPv6 network connectivity to the outside world. (I haven't tried Cloud Run, but I read through the docs and there are no indications [that I could find] that IPv6 is supported, as with other GCP services.)
    - mrwilliamchang 8y ago
      IPv6 TCP and UDP outbound works. :)
      - ivanr 8y ago
        That's great to hear, thanks! Is there a page in the docs where this is documented? I'd also like to know if there are any restrictions (e.g., are all outbound ports open, etc)? If you could comment on when/whether compute instances will get IPv6, that would be great also :)
cagenut 8y ago
can your running container instances mount a filestore nfs endpoint?
- asciimike 8y ago
  Not yet, though I'm looking into both Filestore as well as GCSFuse. The short answer is that read-only mounts are going to be super easy, but read-write is going to get really interesting (especially since there can be N instances all trying to write).
panabee 8y ago
thanks for all the helpful comments here! we run a rails app. if we want to replace heroku with a google cloud service, would cloud run be the best one?
- mattsoldo 8y ago
  I'm doing a talk at Next tomorrow about just that. For now you are probably better of using Ruby on App Engine, assuming you need to use redis as a cache. Another new feature that we launched today is VPC Connectors, which allow Cloud Functions and App Engine to connect to servers/services in a VPC. Cloud Run will have support VPC Connectors soon (it is supported, we just haven't wired up the API/UI). After that, its your choice, they run on similar infrastructure so you just need to decide if you want to live in containerland or source code land.
- mattsoldo 8y ago
  I'll post the example source code here tomorrow after the talk (still tweaking it).
  - panabee 8y ago
    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)?
    - asciimike 8y ago
      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.
      - boundlessdreamz 8y ago
        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.
wgoodall01 8y ago
I'm a student, mainly using GCP for hobby/hackathon projects, and to teach myself. I am massively excited about Cloud Run's free tier---for someone with a budget of zero, being able to get a project off the ground and functional without paying through the nose if you forget to turn down some service is incredibly useful. Getting an unexpected $40 App Engine bill at the end of the month isn't fun. I'm definitely going to check Cloud Run out as a go-to for future projects--it looks like a really good fit for my use case.
- asciimike 8y ago
  We're super excited to see what you build :D Even silly things like https://howdelayedissfo.com https://howdelayedissfo.com (built over the weekend with Cloud Run and Firebase Hosting) are great ways to improve your skills without breaking the bank (projected costs are well within the free tier on both products).
bgray 8y ago
Can you compare Google Run to App Engine Flex? They sound similar.
- chrisbroadfoot 8y ago
  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.

rcconf 8y ago

Hello, I had a question about how Cloud Run handles security between containers being run on the cloud. I assume my container runs alongside other containers on the same host, how do you prevent privilege escalation exploits?

mikehelmick 8y ago
Cloud Run engineer here. Containers are run in gVisor https://github.com/google/gvisor https://github.com/google/gvisor as the container sandbox.
wlhee 8y ago
Cloud Run prevents privilege escalation by using gVisor as sandbox technology. Each container has its own isolated user-space kernel from the host. (Disclaimer: I am Cloud Run dev)
deleted 8y ago
[deleted]

jpdb 8y ago

Is knative build api supported as well?

mikehelmick 8y ago
No, we don't currently support the Knative Build API.
asciimike 8y ago
My understanding is that we're working on having Cloud Build support Tekton [1,2] (which is where the Knative Build API now lives) [1] https://tekton.dev/ https://tekton.dev/ [2] https://cloud.google.com/tekton/ https://cloud.google.com/tekton/

dstaley 8y ago

I'm about to launch an API that uses Cloud Functions for the entire app (it's a pretty simple API anyway). I know that Cloud Run gives me more features (being based on containers and all), but given that my API already runs on Cloud Functions, would I get any performance benefits by moving to Cloud Run?

asciimike 8y ago
Does the Cloud Functions solution meet your current performance requirements? If so, don't worry about moving it. The main benefits you'd see immediately are toolchain (e.g. Docker containers, existing build systems, etc.).
- dstaley 8y ago
  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 milliseconds for Cloud Functions.
  - stewart27 8y ago
    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 infrastructure (generally this is small) but the other part is in your control. For example: if you create a client that takes X seconds to you initialize, your cold start will be at least X seconds. The initialization time will manifest as part of your cold start. This has a few practical implications: * writing code for Cloud Functions is generally more straightforward as single concurrency solves many problems regarding shared variables. You may also see some benefits in terms of monitoring/metrics/logging since you only need to think about one request at a time. * you will likely see a higher incidence of cold starts on Cloud Functions during rapid scale-up, such as in response to a sudden traffic spike * the impact of a given cold start will depend heavily on what you're doing in your container * though I haven't validated this experimentally, I would expect that the magnitude of any given cold start (i.e., total latency contribution) would be roughly the same on Cloud Run as Cloud Functions IF you're running the same code

twa927 8y ago

Does max. RAM usage need to be specified upfront, or what's billed is the live-allocated amount?

mikehelmick 8y ago
Yes, it needs to be specified upfront. The default is 128M and you can specify up to 2G
asciimike 8y ago
"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 https://cloud.google.com/run/pricing You can configure the amount allocated: https://cloud.google.com/run/docs/configuring/memory-limits https://cloud.google.com/run/docs/configuring/memory-limits
- twa927 8y ago
  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.
  - crashedsnow 8y ago
    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)
    - twa927 8y ago
      > 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. I'm not sure what do you mean here, Cloud Run uses Docker which runs regular processes in a cgroup, so it's sufficient to check the cgroup memory usage, right? Yes, Java can always use large heaps but we're running Python and C++ where a process' memory usage directly relates to what a program allocates (even PyPy with GC has this property). > The mitigation in Cloud Run is both concurrency, and that you're only billed while a request is active. When there are memory peaks, larger deployments without container-level concurreny look better. For my example 16GB of RAM allows running 8 containers to get a chance for a 2GB task to complete, but on average 90% of the memory will be wasted. On a single 16GB server I can run 48 tasks with 40% wasted and a high chance of the 2GB tasks finishing. Yes, in this scenario I must handle tasks killed due to OOM but the difference in throughput is so large that it's worth it.

hamandcheese 8y ago

Does cloud run have the same, better, or worse cold start latency compared to cloud functions?

asciimike 8y ago
Cloud Functions is single concurrency, meaning every new request causes a cold start (generally speaking). Cloud Run can be single or multi-concurrency (defaults to 80), meaning one in 80 requests globally causes a cold start (again, generally speaking, assuming the container isn't CPU bound below that, etc.). So, if both are running in single concurrency mode, you'll likely see similar cold start time; however, since you can go multi-concurrent in Run, you'll likely see better performance, especially when scaling up. A nice side effect of this is that your costs will also drop, since you can pack more requests into your instance. Edit: as noted in the other thread, because you control the container image, you can optimize that (e.g. use Alpine instead of Ubuntu) to reduce weight and decrease cold start time. But if you're using a language like Java, it's possible that starting the JVM and framework is going to be more expensive than the OS load time, so it might be a wash.
- hn_throwaway_99 8y ago
  Sorry, just asked a similar question in response to a different comment, but just saw this detailed response. Do you know if there are any plans to add 'warmup requests' to Cloud Run like in App Engine?
  - asciimike 8y ago
    Replied there!

meeks 8y ago

Any chance there will be cron jobs for functions? Right now, I'm using AppEngine just to schedule a function to run.

asciimike 8y ago
Check out Cloud Scheduler (https://cloud.google.com/scheduler/ https://cloud.google.com/scheduler/) which can target an arbitrary HTTP URL, and will support authenticated push to securely target Cloud Functions and Cloud Run (I think this is going to public beta this week).
- stewart27 8y ago
  +1 You can also set up Cloud Scheduler to push to Pub/Sub, which can trigger your function. This is helpful if you don't want your function to be available via a public HTTPS endpoint.
- hn_throwaway_99 8y ago
  Note to Firebase team: I use exactly this (a Cloud Scheduler job that pushes to a pub/sub topic, and then set a Firebase function that runs on a topic trigger) to schedule functions, but would be really nice if I could just create a triggered cron function like this: functions.cron.schedule('0 0 * * *').onSchedule(...) or something like that. Even if it behind the scenes it just did exactly what I'm doing manually now, I see so many questions about cron-triggered functions that it would save a ton of people time searching for what the best route is to take.
  - asciimike 8y ago
    We are working on this right now, so stay tuned :)
jganetsk 8y ago
Cron jobs in knative: https://www.knative.dev/docs/eventing/samples/cronjob-source/ https://www.knative.dev/docs/eventing/samples/cronjob-source...

alexellisuk 8y ago

Hi Mike, this looks great. I took it for a test-drive with some OpenFaaS functions. https://www.openfaas.com/blog/openfaas-cloudrun/ https://www.openfaas.com/blog/openfaas-cloudrun/

lxxvii 8y ago

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?

asciimike 8y ago
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/spec.md#service 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.
crisscrosscrash 8y ago
When would you use Cloud Run vs App Engine Flex? Doesn't App Engine Flex essentially help you run an app in a container and handle scaling too? For example, what if you're running a stateless JVM app like something on Play Framework. Could you run it on either App Engine Flex or Cloud Run, and if so, what considerations would there be for choosing one over the other?
- asciimike 8y ago
  0. Flex doesn't scale to zero, Run does. 1. Flex runs directly on VMs (sharing some GCE networking, access to GPUs, etc.), Run doesn't. Those are the two that come up top of mind. We're working on a more comprehensive "choose your compute product" walkthrough in the near future.
  - crisscrosscrash 8y ago
    Comparison doc in the future would be great! It sounds like there's a bit of overlap. If I'm not up and running yet and just want the most managed solution (least work to run, with the most powerful high level features), is one of these a clear choice? In my case, I don't care as much about low level access, but I just want my app to run quickly and efficiently. App Engine Flex's ability to run multiple services within an application, get load balancing set up, have versions of the app for testing and rollbacks, etc seems great. However, overall I just want to the easiest way to run my stateless set of services.

ivanr 8y ago

Can you provide some information about when you might be adding support for IPv6? It's a deal-breaker for our particular use cases.

mrwilliamchang 8y ago
Can you clarify what is not working for you? IPv6 should work. (I work on Cloud Run).
- ivanr 8y ago
  Sorry, my question was about outbound IPv6. At the backend, we need full IPv4 and IPv6 network connectivity to the outside world. (I haven't tried Cloud Run, but I read through the docs and there are no indications [that I could find] that IPv6 is supported, as with other GCP services.)
  - mrwilliamchang 8y ago
    IPv6 TCP and UDP outbound works. :)
    - ivanr 8y ago
      That's great to hear, thanks! Is there a page in the docs where this is documented? I'd also like to know if there are any restrictions (e.g., are all outbound ports open, etc)? If you could comment on when/whether compute instances will get IPv6, that would be great also :)

cagenut 8y ago

can your running container instances mount a filestore nfs endpoint?

asciimike 8y ago
Not yet, though I'm looking into both Filestore as well as GCSFuse. The short answer is that read-only mounts are going to be super easy, but read-write is going to get really interesting (especially since there can be N instances all trying to write).

panabee 8y ago

thanks for all the helpful comments here! we run a rails app. if we want to replace heroku with a google cloud service, would cloud run be the best one?

mattsoldo 8y ago
I'm doing a talk at Next tomorrow about just that. For now you are probably better of using Ruby on App Engine, assuming you need to use redis as a cache. Another new feature that we launched today is VPC Connectors, which allow Cloud Functions and App Engine to connect to servers/services in a VPC. Cloud Run will have support VPC Connectors soon (it is supported, we just haven't wired up the API/UI). After that, its your choice, they run on similar infrastructure so you just need to decide if you want to live in containerland or source code land.
mattsoldo 8y ago
I'll post the example source code here tomorrow after the talk (still tweaking it).
- panabee 8y ago
  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)?
  - asciimike 8y ago
    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.
    - boundlessdreamz 8y ago
      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.

wgoodall01 8y ago

I'm a student, mainly using GCP for hobby/hackathon projects, and to teach myself. I am massively excited about Cloud Run's free tier---for someone with a budget of zero, being able to get a project off the ground and functional without paying through the nose if you forget to turn down some service is incredibly useful. Getting an unexpected $40 App Engine bill at the end of the month isn't fun. I'm definitely going to check Cloud Run out as a go-to for future projects--it looks like a really good fit for my use case.

asciimike 8y ago
We're super excited to see what you build :D Even silly things like https://howdelayedissfo.com https://howdelayedissfo.com (built over the weekend with Cloud Run and Firebase Hosting) are great ways to improve your skills without breaking the bank (projected costs are well within the free tier on both products).

bgray 8y ago

Can you compare Google Run to App Engine Flex? They sound similar.

chrisbroadfoot 8y ago
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.