Belajar Data Architect - Multi-Cloud & Hybrid Data

#Pendahuluan

Setelah di episode 22 kita mengelola data tidak terstruktur, sekarang kita menghadapi realitas organisasi modern: tidak semua data hidup di satu cloud. Akuisisi membawa beban AWS, pengembangan baru lahir di GCP, dan sebagian data ditahan di on-prem karena regulasi. Arsitek harus merancang agar ini tetap satu ekosistem yang koheren, bukan tiga pulau yang terpisah.

Mengapa episode ini penting? Karena multi-cloud bukan sekadar tren — ia kenyataan bagi banyak organisasi, dan strateginya menentukan biaya, kompleksitas, dan fleksibilitas. Multi-cloud yang salah desain menciptakan jaringan pipeline yang mahal dan data yang terpecah; yang benar desain memberi kebebasan bergerak tanpa mengorbankan konsistensi.

#Mengapa Organisasi Menjadi Multi-Cloud

Alasan	Contoh
Akuisisi & warisan	Perusahaan yang diakuisisi sudah di cloud lain
Regulasi & residency	Data warga negara tertentu wajib di region/cloud tertentu
Negotiation leverage	Multi-vendor = posisi tawar lebih baik
Best-of-breed	Platform terbaik per beban kerja (misal Databricks + BigQuery)
Risk distribution	Hindari single point of failure satu vendor

Penting untuk jujur: multi-cloud lebih mahal dan kompleks daripada single-cloud. Ia dipilih karena alasan di atas, bukan karena "semakin banyak cloud semakin modern".

#Portabilitas Data dengan Open Formats

Kunci utama menghindari lock-in: memisahkan data dari platform. Selama data hidup di format terbuka dan object storage biasa, kalian bisa memindah platform tanpa memindahkan data.

Portabilitas data

LOCK-IN:   data di format proprietary platform → pindah = migrasi besar
PORTER:    data di Parquet/Iceberg di object storage → platform apa pun bisa baca

Open table format (Apache Iceberg, Delta Lake, Hudi) adalah fondasinya: data tersimpan di object storage, metadata di-manage oleh format, dan banyak engine bisa membacanya (Spark, Flink, Trino, BigQuery, Snowflake, Databricks).

Iceberg di object storage (konsep)

s3://data-lake/iceberg/sales/
  metadata/     (schema & snapshot versions)
  data/         (parquet files per partition)

Dampak praktis portabilitas:

Query data yang sama dari BigQuery atau Spark atau Trino — semuanya valid.
Pindah engine transformasi tanpa memindahkan atau menyalin data.
Ada satu copy data, bukan satu per platform (selamatkan biaya dari episode 14).

Warning

Open format mengurangi lock-in platform, tapi bukan berarti tanpa syarat: versi format, kompatibilitas engine, dan komitmen vendor terhadap standar tetap harus diverifikasi. Baca syaratnya sebelum mempercayakan seluruh data — "open" bisa berarti "terbuka dengan catatan".

#Pola Multi-Cloud Data

#1. Single Source of Truth + Read Replicas Lintas Cloud

Data utama di satu tempat, salinan baca (atau virtual access) di cloud lain untuk query lokal:

Pola SOURCE + REPLICA

data utama:  GCS + Iceberg (di GCP)
query lokal: konsumen AWS membaca via virtual table (BigQuery Omni /
             Snowflake data sharing / S3 access ke bucket GCS)
→ tanpa menyalin data secara manual

#2. Federation (Query Lintas Cloud)

Jangan selalu menyalin data — query langsung ke data di cloud lain saat datanya kecil atau kebutuhan sesaat:

Federation contoh

BigQuery Omni     → SELECT ... FROM aws.<region>.<table>  (query data di AWS)
Trino/Presto      → query gabungan multi-source dalam satu SQL
Snowflake sharing → konsumen baca dataset tanpa menyalin

Kapan memakai federation vs replicate:

Situasi	Pilihan
Query sesekali, data kecil	Federation
Query berat dan sering	Replicate ke region lokal
Data besar, butuh konsisten	Satu copy + virtual access

#3. Multi-Region Replication

Untuk ketersediaan tinggi dan akses dekat konsumen, replikasi data ke beberapa region/cloud — dengan satu sumber kebenaran (biasanya pemilik domain menulis, yang lain membaca).

#Strategi Vendor

Strategi vendor untuk multi-cloud data:

Prinsip strategi vendor

1. Standarkan format & metadata (Iceberg + schema registry) — bukan vendor
2. Jaga pipeline portable: SQL (dbt) di atas engine yang bisa diganti
3. Komitmen bertingkat: platform inti di satu vendor, tanpa menutup pintu
4. Evaluasi exit-cost setiap tahun: berapa biaya pindah? (episode 14)
5. Hindari fitur proprietary untuk hal yang fundamental

Arsitek harus selalu bisa menjawab: "kalau besok kita pindah dari vendor X, apa yang kita tinggalkan?" Jika jawabannya "semuanya", kalian sedang membangun penjara.

#Praktik: Desain Multi-Cloud

#Step 1: Petakan Data dan Persyaratannya

Peta multi-cloud data

dataset          cloud_saat_ini  kebutuhan_residency  konsumen
gold sales       GCP              -                    BI GCP
raw log APAC     on-prem          lokal wajib          pipeline lokal
feature store    AWS              -                    model AWS

#Step 2: Tetapkan Source of Truth per Domain

Satu domain = satu sumber penulisan (episode 12). Yang lain membaca via federation atau replica.

#Step 3: Standarkan Format

Semua data antar-cloud memakai Iceberg/Parquet + schema registry. Tidak ada format proprietary untuk data yang dibagikan.

#Step 4: Pilih Pola per Aliran

Query ringan lintas cloud → federation.
Query berat lintas cloud → replica dengan sync via CDC (episode 7).
Data wajib lokal → tetap di region tersebut, hanya metadata dibagikan.

#Step 5: Dokumentasikan dan Evaluasi

Dokumentasikan arsitektur di blueprint (episode 17) dan evaluasi strategi vendor tiap tahun — termasuk biaya aktual multi-cloud vs single-cloud.

Tip

Jangan mulai dengan multi-cloud untuk semua data. Mulai dengan satu aliran lintas cloud yang dipaksa kebutuhan (misal residency), buktikan pipeline-nya stabil, baru perluas. Multi-cloud yang dipaksakan untuk semua hal adalah cara paling pasti membakar budget dan jam kerja tim.

#Penutup

Inti yang harus dibawa pulang:

Multi-cloud adalah kenyataan (akuisisi, regulasi, leverage), tapi lebih mahal dan kompleks — pilih karena alasan, bukan tren.
Open formats (Iceberg/Delta) + object storage adalah kunci portabilitas data.
Pola multi-cloud: single source of truth + replica, federation, dan multi-region replication.
Strategi vendor: standarkan format & pipeline, hitung exit-cost, hindari fitur proprietary fundamental.
Terapkan multi-cloud bertahap per aliran yang dipaksa kebutuhan.

Di episode 24 selanjutnya kita akan membahas Data Architecture Review & ADR — bagaimana keputusan arsitektur direview dan didokumentasikan agar bisa dipertanggungjawabkan. Sampai jumpa di episode 24!