Google Cloud recently announced the general availability of Cloud Run jobs, a serverless option to execute scripts and jobs that do not respond to HTTP requests. A new execution environment provides increased CPU, network performance, and support for network file systems.
Unlike a Cloud Run service, which handles HTTP requests, a Cloud Run job only runs its tasks and cannot accept parameters at execution. Introduced in preview at Google I/O, Cloud Run jobs are designed to run batch data transformations, database migrations, nightly reports, and run-to-completion jobs, helping the migration of legacy scripts into a serverless environment. Karolina Netolicka, group product manager at Google, and Bex Heart, product marketing manager, explain:
Cloud Run was initially designed around the needs of websites or APIs serving, allowing users to run "services" that responded to HTTP requests or events (...) But the same organizations that used Cloud Run (...) wished there was a way to use serverless environments to run other workloads that didn’t quite fit into the HTTP request paradigm.
Google is not the only cloud provider offering the option to schedule tasks, with Shekhar Jha, distinguished engineer at Capital One, comparing AWS ECS and Google Cloud run jobs.
Google released a new execution environment that provides increased CPU and network performance and supports network file systems, facilitating the migration of existing applications: Cloud Run supports Cloud Filestore, self-managed NFS servers, and FUSE, the open-source adapter that allows mounting a Cloud Storage bucket as a local file system. Netolicka and Heart add:
The second-generation execution environment is fully compatible with all Linux features, making it easier to move existing containers to Cloud Run. This means that software that previously didn’t run in Cloud Run due to unimplemented system call issues can now run in Cloud Run’s second-generation execution environment.
Commenting on a video about the new features, Niklas Higi, co-founder and CTO at Kombo, highlights some limitations:
We could not use Cloud Run jobs for a long-running task use case we had and had to resort to managing a GKE cluster and creating K8S jobs due to the following two limitations: there's no way to pass arguments to individual executions of jobs (...) and the maximum execution time, just like regular Cloud Run, is limited to 1 hour.
Cloud Run Jobs has a default task timeout setting of 10 minutes that can be increased up to 1 hour. There is no explicit timeout for the job, depending only on the completion of all tasks. As for the pricing table, the first 240,000 vCPU-seconds and 450,000 GiB-seconds are free each month.