Multi Cloud #
Multi cloud adalah penggunaan layanan dari dua atau lebih cloud provider secara bersamaan untuk workload yang berbeda — atau bahkan workload yang sama. Ini adalah strategi yang sering terdengar menarik di atas kertas: tidak bergantung pada satu vendor, bisa pilih yang terbaik dari masing-masing provider, terlindungi dari outage provider tunggal. Tapi realita implementasinya jauh lebih kompleks dari promisinya. Memahami kapan multi cloud benar-benar memberikan nilai — dan kapan ia hanya menambah beban operasional — adalah keputusan arsitektur yang penting.
Apa itu Multi Cloud #
Multi cloud berarti menggunakan lebih dari satu public cloud provider. Penting untuk membedakannya dari hybrid cloud yang menggabungkan public cloud dengan private cloud atau on-premise.
Definisi yang Sering Tertukar:
Multi Cloud:
→ AWS untuk compute + GCP untuk ML + Azure untuk Office 365 integration
→ Dua atau lebih PUBLIC cloud provider
→ Bisa intentional (pilihan strategis) atau tidak sengaja
(akuisisi perusahaan yang sudah pakai provider berbeda)
Hybrid Cloud:
→ Public cloud + private cloud/on-premise
→ Data sensitif di on-premise, workload fleksibel di public cloud
→ Akan dibahas di artikel berikutnya
Yang penting:
Multi cloud ≠ Hybrid cloud
Banyak orang menggunakannya secara bergantian padahal berbeda
Mengapa Organisasi Masuk ke Multi Cloud #
Ada beberapa motivasi yang mendorong adopsi multi cloud — dan tidak semua sama validnya.
Alasan yang Valid #
Best-of-breed services:
→ GCP punya BigQuery yang sangat kuat untuk analytics
→ AWS punya ekosistem managed services yang paling lengkap
→ Azure punya integrasi native dengan ekosistem Microsoft
→ Beberapa organisasi memilih provider berbeda berdasarkan
keunggulan spesifik per use case
Regulasi dan data residency:
→ Beberapa negara/industri mensyaratkan data disimpan di provider
atau region tertentu yang mungkin hanya tersedia di satu provider
Redundansi provider:
→ Untuk workload dengan SLA sangat tinggi, tidak bergantung
pada satu provider bisa mengurangi risiko regional + provider outage
Akuisisi dan merger:
→ Perusahaan yang diakuisisi sudah pakai provider berbeda
→ Migrasi penuh memakan waktu dan biaya, multi cloud jadi kondisi sementara
Alasan yang Perlu Dikritisi #
"Untuk menghindari vendor lock-in":
→ Logis secara teori, tapi menjalankan workload yang sama
di dua provider sekaligus sangat mahal dan kompleks
→ Lock-in yang sesungguhnya sering lebih ke data dan arsitektur,
bukan ke platform — dan ini tidak selesai hanya dengan multi cloud
"Untuk negosiasi harga":
→ Memang memberikan leverage, tapi butuh skala yang sangat besar
agar diskoun negosiasi lebih besar dari overhead operasional multi cloud
"Karena semua orang melakukannya":
→ Bukan alasan arsitektur yang baik
Kompleksitas yang Datang Bersama Multi Cloud #
Multi cloud bukan gratis. Setiap provider yang ditambahkan membawa overhead yang signifikan.
Overhead Operasional Multi Cloud:
Skills gap:
→ Setiap provider punya cara sendiri untuk IAM, networking,
storage, monitoring, dan billing
→ Tim perlu expertise di semua provider yang digunakan
→ Engineer yang "jack of all clouds" lebih langka dan mahal
Tooling yang berlipat:
→ Terraform bisa abstrak sebagian, tapi bukan semuanya
→ Monitoring: bagaimana agregasi metrics dari dua provider?
→ Security: bagaimana standarisasi posture keamanan?
→ Billing: bagaimana track dan optimasi biaya dari dua tempat?
Networking antar provider:
→ Data transfer antar cloud provider dikenakan biaya egress
→ Latensi lebih tinggi dibanding komunikasi dalam satu provider
→ Koneksi private (dedicated link) antar provider = biaya tambahan
Konsistensi deployment:
→ Arsitektur yang sama harus dikonfigurasi dua kali
dengan cara yang berbeda per provider
→ Drift konfigurasi antar provider sulit dideteksi
Studi industri secara konsisten menunjukkan bahwa kompleksitas multi cloud sering melebihi nilai yang didapat, terutama untuk organisasi dengan tim yang tidak cukup besar. Banyak organisasi yang mengklaim “multi cloud” sebenarnya hanya menggunakan satu provider untuk workload utama dan provider lain untuk satu atau dua layanan spesifik — yang secara operasional jauh lebih manageable.
Pola Multi Cloud yang Lebih Pragmatis #
Ada cara menggunakan lebih dari satu provider tanpa harus menanggung kompleksitas penuh multi cloud.
Pola 1 — Segmentasi Workload
Provider A: semua compute dan storage utama
Provider B: layanan spesifik yang tidak ada di Provider A
(misalnya: layanan ML tertentu, specialized database)
Keuntungan: tidak ada duplikasi workload, setiap provider
melakukan apa yang ia lakukan terbaik
Pola 2 — SaaS di Atas Multi Provider
Gunakan SaaS tools yang berjalan di atas cloud provider
tanpa kamu perlu manage multi cloud sendiri
→ Email, collaboration, analytics SaaS yang kebetulan berjalan
di provider berbeda tidak berarti kamu "multi cloud"
Pola 3 — Provider Utama + Cadangan Dingin
Semua workload di Provider A
Infrastructure-as-Code untuk Provider B tersimpan tapi
tidak di-deploy kecuali Provider A mengalami outage besar
→ Tidak ada biaya duplikasi, tapi ada jalur evakuasi
Kapan Multi Cloud Benar-Benar Masuk Akal #
Multi cloud layak dipertimbangkan jika:
✓ Organisasi besar dengan tim cloud yang dedicated per provider
✓ Kebutuhan "best-of-breed" yang spesifik dan terukur
(misalnya: BigQuery untuk analytics, bukan hanya "karena lebih baik")
✓ Regulasi yang mengharuskan penggunaan provider lokal tertentu
sekaligus butuh global provider
✓ SLA yang sangat ketat yang membutuhkan redundansi provider level
Multi cloud terlalu mahal untuk:
✗ Startup dan organisasi menengah dengan tim kecil
✗ Sekedar "menghindari lock-in" tanpa rencana konkret
✗ Workload yang tidak memanfaatkan keunggulan spesifik tiap provider
Ringkasan #
- Multi cloud ≠ hybrid cloud — multi cloud adalah dua atau lebih public cloud provider; hybrid cloud menggabungkan public cloud dengan private/on-premise.
- Motivasi terkuat multi cloud adalah best-of-breed dan regulasi — bukan “menghindari vendor lock-in” secara generik.
- Kompleksitas operasional multi cloud sangat nyata — skills gap, tooling berlipat, networking antar provider, dan overhead manajemen biaya.
- Kebanyakan “multi cloud” di lapangan sebenarnya adalah segmentasi workload — satu provider utama, provider lain untuk layanan spesifik. Ini jauh lebih manageable.
- Data egress antar provider bisa menjadi biaya signifikan — hitung ini sebelum memutuskan arsitektur multi cloud.
- Skala dan kapasitas tim menentukan apakah multi cloud layak — untuk tim kecil, fokus menguasai satu provider dengan baik biasanya memberikan nilai lebih.