What I Learned About Cloud Run Instances

Google introduced Cloud Run instances as a fourth execution model alongside Services, Jobs, and Worker Pools, according to a first-person account of early access to the feature. The author tested an AI agent on a Cloud Run Service with a mounted Cloud Storage volume and an ephemeral disk, and found the agent handled long-lived sessions, scaled to zero to minimize costs, and resumed the same session when called later. The author reported that Cloud Storage FUSE mounting still suffered high latency and lacked true POSIX locking, and that the ephemeral disk reset each time the service scaled to zero, leaving the distinction between Instances and Services unclear.

Cloud Run is my primary deployment platform when I experiment with AI Workloads or build samples for conferences and codelabs. When I got early access to its new feature called Cloud Run instances https://cloud.google.com/run/docs/instances/create-and-manage-instances?utm campaign=CDR 0x71604355 platform b561110825&utm medium=external&utm source=blog , I was a bit confused. I mean, Cloud Run already offered three execution models: Services for transactions and request-response apps, Jobs for batch processing, and Worker Pools for background tasks. Why introduce a fourth option? Initially I thought that my “aha” moment would come when I tried to build an AI agent that runs long-lived sessions and needs to persist the session’s temporary data locally. Then I tried to find a difference between using an Instance and deploying the agent as a Cloud Run Service. I mounted a storage volume https://cloud.google.com/run/docs/configuring/services/cloud-storage-volume-mounts?utm campaign=CDR 0x71604355 platform b561110825&utm medium=external&utm source=blog to my service and instrumented the agent with a tool to read and write state data to that volume. I also added an ephemeral disk https://cloud.google.com/run/docs/configuring/services/ephemeral-disk?utm campaign=CDR 0x71604355 platform b561110825&utm medium=external&utm source=blog to store temporary data that the agent generated mid-execution. The agent managed long-lived sessions without a problem. It scaled to zero minimizing costs when left alone and resumed to the same session operation when called later. The known problems of mounting Cloud Storage buckets via FUSE such as high latency and lack of true POSIX locking were there. And my ephemeral disk reset each time the service scaled to zero. “Well,” I thought, “it would be nice to have storage that behaves like a persistent local disk.” However the same would be true for Cloud Run Instances too. This experience supported my initial confusion about Instances.