DevOps
Google Cloud Managed Services vs Raw Compute: Kapan Pakai Yang Mana
Juli 202510 menit baca
Foto oleh Unsplash
Cloud Run adalah pilihan default yang tepat untuk API HTTP atau web app apa pun karena otomatis menangani scaling, SSL, dan penagihan per request. Beralih ke Compute Engine hanya jika Anda butuh kontrol level OS—seperti modul kernel khusus, akses raw socket, workload GPU, atau proses background persisten yang tidak cocok dengan model request-response.
Request harus merespons dalam 60 menit, koneksi stateful seperti WebSocket memerlukan pengaturan revisi khusus, dan daemon background yang butuh CPU persisten tidak bisa dijalankan. Selain itu, Cloud Run secara default akan scale ke nol, yang dapat menambah latensi 2–4 detik pada request pertama setelah idle—set --min-instances 1 untuk mencegah cold start di endpoint produksi.
Cloud SQL menangani backup, point-in-time recovery, update versi minor otomatis, dan failover high-availability secara otomatis. Biaya tambahannya relatif kecil dibanding self-hosting Postgres di VM, sementara penghematan operasional sangat besar—terutama untuk tim kecil yang seharusnya harus mengelola patching OS, disk, dan failover secara manual.
Cloud SQL Auth Proxy berjalan sebagai sidecar di Cloud Run dan menangani autentikasi IAM serta terminasi TLS tanpa mengekspos database ke IP publik. String koneksi menggunakan path Unix socket alih-alih hostname, sehingga tidak diperlukan whitelist IP di firewall VPC—izin service account IAM adalah satu-satunya kontrol akses yang dibutuhkan.
GKE cocok ketika Anda benar-benar membutuhkan fitur spesifik Kubernetes seperti custom operator, StatefulSet untuk database berkluster, jaringan antar-layanan yang kompleks dengan service mesh, atau portabilitas multi-cloud. GKE bukan pilihan yang tepat hanya karena tim ingin memakai Kubernetes—GKE menambah kompleksitas operasional yang besar, termasuk upgrade cluster, manajemen node pool, dan konfigurasi RBAC.
Foto oleh Unsplash
Google Cloud menawarkan begitu banyak layanan compute dan data sehingga memilih di antaranya terasa seperti jebakan. Cloud Run, GKE, App Engine, Compute Engine, Cloud Functions—ditambah lapisan terpisah dari managed data services. Setelah mengelola infrastruktur untuk project-project Commsult Indonesia di GCP selama beberapa tahun, saya telah mengembangkan mental model sederhana untuk layanan mana yang cocok di mana.
| Dimensi | Managed Services | Raw Compute |
|---|---|---|
| Kontrol | Google yang mengelola patching, scaling, dan failover | Kontrol penuh atas OS, runtime, dan konfigurasi |
| Kecepatan setup | Deploy Cloud Run atau App Engine dalam hitungan menit | Provisioning VM Compute Engine, konfigurasi networking dan OS sendiri |
| Model biaya | Bayar per request atau pemakaian, bisa scale ke nol | Bayar untuk kapasitas VM yang di-reserve, dipakai atau tidak |
| Overhead operasional | Google yang menangani patch OS dan load balancing | Anda yang menangani patching, monitoring, dan capacity planning |
| Kustomisasi | Terbatas pada runtime yang didukung platform | OS, kernel module, atau binary custom apa pun |
| Paling cocok untuk | API stateless, beban kerja event-driven, iterasi cepat | Beban kerja legacy, networking custom, software berat GPU atau terikat lisensi |
Setiap layanan compute GCP berada dalam spektrum antara kontrol maksimal (raw VM) dan kenyamanan maksimal (fully managed). Trade-off-nya nyata: lebih banyak kontrol berarti lebih banyak beban operasional. Lebih banyak kenyamanan berarti menerima batasan—runtime tetap, batas timeout request, cold start, vendor lock-in.
Cloud Run adalah tempat saya memulai setiap API HTTP atau web app baru. Ini adalah platform container fully managed: berikan image Docker, platform menjalankannya, menskalakan ke nol saat idle, dan scale up sesuai permintaan. Penagihan per request membuat biaya sangat efisien untuk API dengan traffic yang bervariasi.
Raw Compute Engine VM cocok ketika Anda membutuhkan kontrol level OS: modul kernel khusus, akses raw socket, workload GPU, atau proses background persisten. Saya juga menggunakan GCE ketika perlu menjalankan Docker Swarm di beberapa VM untuk tooling internal.
GCP Service Decision Tree
─────────────────────────
Need to run code?
│
▼
┌─────────────────────────────────────────┐
│ Do you need OS-level control? │
│ (custom kernel, raw sockets, GPU, etc.) │
└───────┬──────────────────┬──────────────┘
│ YES │ NO
▼ ▼
Compute Engine Stateless HTTP?
(raw VM, GCE) │
┌─────┴──────┐
│ YES │ NO
▼ ▼
Cloud Run Need containers?
(fully │
managed) ┌──┴───┐
│ YES │ NO
▼ ▼
GKE App Engine
(k8s) (PaaS, flex/std)
Need managed data?
├── Relational → Cloud SQL (Postgres/MySQL)
├── Serverless → Firestore / Spanner
├── Cache → Memorystore (Redis)
└── Object → Cloud Storage (GCS)Gunakan 'gcloud run services describe SERVICE --format=json | jq .status.traffic' untuk memeriksa pembagian traffic saat ini di semua revisi. Berguna saat melakukan rollout bertahap.
Di lapisan data, kalkulasinya lebih sederhana: kecuali ada alasan yang sangat spesifik untuk self-host database, gunakan Cloud SQL untuk Postgres atau MySQL. Cloud SQL menangani backup, point-in-time recovery, update versi minor otomatis, dan failover high-availability.
Ketika Cloud Run terhubung ke Cloud SQL, pendekatan yang direkomendasikan adalah Cloud SQL Auth Proxy, yang menangani autentikasi IAM dan terminasi TLS tanpa mengekspos database ke IP publik. String koneksi menggunakan path Unix socket alih-alih hostname.
# Deploy NestJS API to Cloud Run (managed, scale-to-zero)
gcloud run deploy my-api --image gcr.io/my-project/my-api:latest --platform managed --region asia-southeast2 --allow-unauthenticated --set-env-vars DATABASE_URL=$$DATABASE_URL --min-instances 0 --max-instances 10 --memory 512Mi --cpu 1
# Connect to Cloud SQL without a public IP (via Cloud SQL Auth Proxy)
gcloud run services update my-api --add-cloudsql-instances my-project:asia-southeast2:my-postgres --set-env-vars "DB_HOST=/cloudsql/my-project:asia-southeast2:my-postgres"
# Compare: raw Compute Engine VM for same workload
gcloud compute instances create my-api-vm --machine-type e2-medium --image-family debian-12 --image-project debian-cloud --zone asia-southeast2-a --tags http-server,https-server
# Then manually: install Node, set up systemd, configure nginx reverse proxy,
# handle SSL, set up monitoring, auto-start on reboot...GKE adalah pilihan tepat ketika Anda membutuhkan fitur spesifik Kubernetes: custom operator, StatefulSet, jaringan antar-layanan yang kompleks dengan service mesh, atau portabilitas multi-cloud. GKE menambah kompleksitas operasional yang substansial.
Scale-to-zero Cloud Run menghemat biaya untuk dev dan staging, tapi untuk API produksi dengan traffic stabil, minimum 1 instance mencegah cold start—yang dapat menambah 2-4 detik latensi. Set --min-instances 1 untuk endpoint produksi yang sensitif terhadap latensi.
Sistem ERP yang saya bantu kelola di Commsult Indonesia berjalan di: Cloud Run untuk NestJS API, Cloud SQL untuk Postgres 16, Memorystore untuk Redis, Cloud Storage untuk dokumen dan PDF, serta Compute Engine VM untuk monitoring Prometheus/Grafana internal.
Decision tree-nya sederhana: mulai dengan Cloud Run untuk workload HTTP apa pun. Jika butuh kontrol OS atau GPU, gunakan Compute Engine. Jika butuh fitur spesifik Kubernetes, gunakan GKE. Untuk data: Cloud SQL untuk database, Memorystore untuk Redis, Cloud Storage untuk objek.
Sumber & Bacaan Lanjutan