# Google Cloud Managed Services vs Raw Compute: Kapan Pakai Yang Mana

> Framework keputusan praktis untuk memilih antara Cloud Run, GKE, Cloud SQL, dan raw Compute Engine VM—berdasarkan workload nyata, bukan marketing.

URL: https://www.matthewswong.com/id/blog/google-cloud-managed-services-vs-raw-compute/

- Author: Matthews Wong (https://www.matthewswong.com/id/about/)
- Published: 2025-06-10
- Updated: 2026-10-17
- Category: DevOps

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 di GCP selama beberapa tahun, saya telah mengembangkan mental model sederhana untuk layanan mana yang cocok di mana.

## Perbedaan Mendasar: Kontrol vs Kenyamanan

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: Pilihan Default untuk Workload HTTP

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.

### Kapan Memakai Compute Engine

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.

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

## Managed Data Services: Hampir Selalu Pilihan Tepat

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.

### Menghubungkan Layanan: Cloud SQL Auth Proxy

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.

> **Perhatikan Biaya**

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

## GKE: Ketika Anda Benar-Benar Butuh Kubernetes

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.

## Contoh Stack: ERP di GCP

Sebuah sistem ERP di GCP bisa 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.

## Membuat Keputusan

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

- Google Cloud — Dokumentasi Cloud Run — https://cloud.google.com/run/docs
- Google Cloud — Membuat dan memulai VM instance — https://cloud.google.com/compute/docs/instances/create-start-instance
- Google Cloud — Memilih opsi compute — https://cloud.google.com/blog/topics/developers-practitioners/where-should-i-run-my-stuff-choosing-google-cloud-compute-option

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

## Source links

- https://cloud.google.com/run/docs
- https://cloud.google.com/compute/docs/instances/create-start-instance
- https://cloud.google.com/blog/topics/developers-practitioners/where-should-i-run-my-stuff-choosing-google-cloud-compute-option

## FAQ

### Kapan sebaiknya memakai Cloud Run dibanding VM Compute Engine?

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.

### Apa saja batasan praktis ketika menjalankan aplikasi di Cloud Run?

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.

### Mengapa memakai Cloud SQL daripada menjalankan Postgres sendiri di VM?

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.

### Bagaimana cara kerja Cloud SQL Auth Proxy saat menghubungkan Cloud Run ke Cloud SQL?

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.

### Kapan GKE benar-benar menjadi pilihan yang tepat?

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.

---

- HTML version: https://www.matthewswong.com/id/blog/google-cloud-managed-services-vs-raw-compute/
- English: https://www.matthewswong.com/en/blog/google-cloud-managed-services-vs-raw-compute/
- Site index for agents: https://www.matthewswong.com/llms.txt
- Sitemap: https://www.matthewswong.com/sitemap.xml
- API description (OpenAPI): https://www.matthewswong.com/openapi.json