DevOps
Cloud Run vs Cloud Functions: Platform Serverless Google Mana yang Harus Anda Gunakan?
Maret 202510 menit baca
DevOps
Pada Agustus 2024, Google menggabungkan Cloud Functions (generasi ke-2) ke dalam payung Cloud Run dan menamainya ulang sebagai 'Cloud Run functions'. Perubahan nama ini menyampaikan sesuatu yang penting: di balik layar, keduanya kini berbagi infrastruktur yang sama. Namun pengalaman developer, model harga, dan kasus penggunaan yang tepat masih berbeda secara signifikan. Saya telah men-deploy keduanya di produksi di Commsult Indonesia — Cloud Run untuk REST API dan background worker kami, Cloud Run functions untuk event-driven Pub/Sub processor dan webhook handler. Berikut breakdown jujur berdasarkan apa yang benar-benar saya jalankan.
Sebelum rebranding, Cloud Functions (generasi ke-2) sebenarnya sudah berjalan di atas Cloud Run secara internal. Google membuatnya eksplisit dengan menggabungkan dua produk di bawah satu merek. Cloud Run functions kini merupakan penawaran FaaS Google — fungsi HTTP atau event-triggered satu tujuan dengan lingkungan eksekusi terkelola. Cloud Run adalah platform berbasis container untuk hal yang lebih kompleks: API multi-route, job yang berjalan lama, server WebSocket, atau workload yang membutuhkan base image khusus. Perbedaan utamanya bukan lagi pada infrastruktur — melainkan pada model deployment dan cara Anda memandang kode Anda.
Cloud Run men-deploy container apa pun yang mendengarkan pada suatu port. Anda membawa Dockerfile sendiri, memilih runtime bahasa apa pun, mengemas dependensi, dan mendefinisikan endpoint health check. Satu layanan Cloud Run dapat menangani banyak route — Anda dapat men-deploy seluruh aplikasi Express atau FastAPI sebagai satu layanan. Cloud Run mendukung hingga 80 permintaan konkuren per instance secara default (dapat dikonfigurasi hingga 1000), yang secara dramatis mengurangi cold start untuk traffic bursty dibandingkan isolasi fungsi per-permintaan. Waktu startup bergantung pada ukuran container — container Node.js yang ramping mulai dalam 1-3 detik; container Python berat dengan dependensi ML mungkin memerlukan 10-15 detik.
Cloud Run functions (sebelumnya Cloud Functions generasi ke-2) dioptimalkan untuk eksekusi satu tujuan yang didorong oleh event. Anda menulis function handler di Node.js, Python, Go, Java, Ruby, atau PHP — tanpa Dockerfile. Trigger meliputi permintaan HTTP, pesan Pub/Sub, event Cloud Storage, penulisan Firestore, dan Cloud Scheduler. Platform mengelola runtime, menangani konkurensi secara internal, dan melakukan scale to zero ketika idle. Untuk konsumen Pub/Sub yang memproses 100 pesan per hari, Cloud Run functions jauh lebih sederhana dibandingkan memelihara layanan Cloud Run dengan push subscription Pub/Sub.
Dari pengalaman saya: gunakan Cloud Run functions untuk apa pun yang dipicu oleh event Google Cloud (Pub/Sub, GCS, Firestore, Scheduler) dan Cloud Run untuk apa pun yang menerima traffic HTTP sembarang. Faktor penentu bukan kompleksitas — melainkan jenis trigger. Webhook processor yang kompleks sekalipun lebih cocok untuk Cloud Run functions daripada API multi-route sederhana di Cloud Run. Begitu Anda membutuhkan base image khusus atau ingin menangani banyak route secara efisien, beralih ke Cloud Run.
Kedua platform menagih berdasarkan CPU, memori, dan permintaan yang diproses. Tier gratis mencakup 180.000 vCPU-detik, 360.000 GiB-detik, dan 2 juta permintaan per bulan di us-central1. Untuk workload traffic rendah, kedua platform pada dasarnya tidak mengenakan biaya. Perbedaan muncul pada skala. Dukungan Cloud Run untuk 80+ permintaan konkuren per instance berarti satu instance menangani lonjakan traffic yang akan memunculkan 80 instance Cloud Run functions terpisah. Jika fungsi Anda memerlukan 200ms untuk dieksekusi dan biayanya $0,000000231 per vCPU-detik, 1 juta permintaan per hari menghabiskan sekitar $5-10/bulan — seringkali lebih murah daripada mempertahankan layanan Cloud Run dengan skala minimum.
Cold start adalah perhatian operasional utama pada platform serverless apa pun. Cold start Cloud Run functions berjalan 200-800ms untuk runtime ringan (Node.js, Python tanpa impor berat). Cold start Cloud Run sepenuhnya bergantung pada container Anda — container minimal menambahkan 1-3 detik; container yang memuat model TensorFlow mungkin memerlukan 30+ detik. Model konkurensi Cloud Run membantu: begitu instance sudah hangat, ia menangani permintaan konkuren tanpa memunculkan instance baru. Untuk traffic dengan lonjakan yang dapat diprediksi, atur minimum instance Cloud Run ke 1 untuk menghilangkan cold start sepenuhnya (biayanya sekitar $10-15/bulan untuk alokasi CPU minimal).
┌─────────────────────────────────────────────────────────┐
│ Google Cloud Serverless Platforms │
├─────────────────────────┬───────────────────────────────┤
│ Cloud Run │ Cloud Run Functions │
│ (container-based) │ (event-driven FaaS) │
├─────────────────────────┼───────────────────────────────┤
│ • Any language/runtime │ • Managed runtime (no Docker) │
│ • Multi-route HTTP │ • Single-purpose handler │
│ • 80+ concurrent req │ • Event triggers (Pub/Sub etc) │
│ • Custom base image │ • Scale to zero by default │
│ • Longer cold starts │ • 200-800ms cold starts │
└─────────────────────────┴───────────────────────────────┘Instance Cloud Run menangani banyak permintaan konkuren. Cloud Run functions, secara default, menangani satu permintaan per instance (meskipun kini Anda dapat mengonfigurasi konkurensi hingga 1000 untuk fungsi yang dipicu HTTP). Untuk fungsi yang memproses pesan Pub/Sub selama 10 detik, dengan konkurensi default, 100 pesan simultan memunculkan 100 instance. Dengan Cloud Run dan konkurensi diatur ke 100, satu instance menangani semuanya. Hal ini sangat berpengaruh pada biaya dan frekuensi cold start saat memproses aliran event bervolume tinggi.
Saya melakukan kesalahan ini di awal: saya men-deploy layanan Cloud Run untuk webhook handler yang menerima mungkin 500 permintaan per hari. Layanan tersebut berjalan dengan minimum 1 instance untuk menghindari cold start, menghabiskan $12/bulan untuk komputasi yang hampir idle. Cloud Run function akan menangani 500 permintaan tersebut dengan biaya sebagian sen dengan nol biaya cold start karena pola traffic yang jarang sangat cocok dengan model scale-to-zero. Sesuaikan ukuran dengan pola traffic: traffic berkelanjutan berfrekuensi tinggi menguntungkan Cloud Run dengan konkurensi; traffic bursty berfrekuensi rendah menguntungkan Cloud Run functions dengan scale-to-zero.
Di Commsult Indonesia, saya menggunakan Cloud Run untuk semua web API dan scheduled background job kami, serta Cloud Run functions untuk integrasi event GCP apa pun (Pub/Sub, GCS trigger, hook Firestore onCreate). Jika saya memulai proyek baru hari ini, saya akan default ke Cloud Run untuk API dan menggunakan Cloud Run functions hanya untuk kode event-driven glue. Model container Cloud Run lebih portabel — Anda dapat menjalankan container yang sama di DigitalOcean, GKE, atau setup Docker lokal, membuat development dan debugging lokal jauh lebih mudah.
Berpindah dari Cloud Run functions ke Cloud Run cukup mudah: bungkus function handler Anda dalam server HTTP sederhana (Express untuk Node.js, Flask untuk Python), kontainerisasi, dan deploy ke Cloud Run. Trigger Pub/Sub berpindah dari trigger fungsi native ke push subscription Cloud Run. Berpindah dari Cloud Run ke Cloud Run functions lebih sulit karena Cloud Run functions memberlakukan model satu titik masuk — Anda perlu memdekomposisi aplikasi multi-route menjadi fungsi-fungsi terpisah. Rencanakan arsitektur Anda sebelum berkomitmen pada satu model, terutama jika Anda mengharapkan layanan akan berkembang.
Sumber & Bacaan Lanjutan