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, 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 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 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.