Belajar Cloud Architect - Hybrid & Multi-Cloud

#Pendahuluan

Setelah episode 15 (multi-region dalam satu provider), pertanyaan yang sering muncul berikutnya: kenapa tidak pakai banyak provider sekaligus? Multi-cloud terdengar hebat di slide — hindari lock-in, gunakan kekuatan tiap vendor. Tapi seperti semua trade-off (episode 3), ia punya harga nyata.

Episode ini membedah tiga konsep yang sering tertukar: multi-cloud (banyak provider), hybrid (cloud + on-premise), dan portabilitas (seberapa mudah pindah). Tujuannya bukan mengajak kalian ke satu arah, melainkan membuat keputusan berdasarkan bukti, bukan slogan.

#Hybrid: Cloud + On-Premise

#Mengapa Hybrid

Hybrid cloud menghubungkan cloud dengan datacenter on-premise. Alasan umum:

• Data sensitif tetap lokal — hukum atau kebijakan melarang data di cloud (episode 15).
• Investasi infrastruktur lama — tidak semua bisa dipindah sekaligus (episode 24).
• Latency — aplikasi lokal harus dekat dengan sistem yang tersisa on-premise.
• Kapasitas burst — puncak beban dialihkan ke cloud (cloud bursting).

#Pola Koneksi

Koneksi hybrid mengikuti pola episode 6: private link (Direct Connect/Interconnect/ExpressRoute) sebagai primary, VPN sebagai failback. Kedua sisi harus bisa saling mencapai via jaringan yang andal.

Penting: hybrid menambah permukaan keamanan. Setiap jalur koneksi adalah serangan potensial — routing, firewall, dan monitoring harus meliputi keduanya (episode 6, 19).

#Multi-Cloud: Mengapa Sering Gagal

#Argumen Untuk

• Hindari lock-in — tidak bergantung pada satu vendor.
• Best-of-breed — pakai kekuatan terbaik tiap provider (GCP untuk data, AWS untuk skala).
• Redundansi — provider satu down, yang lain jalan.

#Realita yang Sering Terlewat

• Biaya ganda: tim, tooling, proses, dan keahlian di dua provider.
• Kompleksitas operasional: dua console, dua sistem IAM, dua observability.
• Fitur tidak sama: fitur yang ada di satu provider tidak tentu ada di provider lain.
• Portabilitas yang dibayar jarang terpakai: mayoritas workload tidak pernah dipindah.

#Kapan Multi-Cloud Benar-Benar Masuk Akal

• Regulatory — data wajib tinggal di provider tertentu (jarang).
• Best-of-breed — satu workload spesifik (misal AI) lebih kuat di vendor lain (episode 17).
• Leverage negosiasi — kompetisi harga antar-provider.
• Redundansi regulatorik — ketika satu provider dilarang di suatu negara.

Jika salah satu kebutuhan ini nyata, multi-cloud layak. Jika tidak, biayanya tidak akan pernah terbayar.

#Portabilitas dan Abstraction Layer

#Arti Sebenarnya

Portabilitas bukan "bisa pindah provider kapan saja". Ia adalah seberapa murah pindah — biaya teknis, operasional, dan waktu. Pindah tetap mahal; portabilitas hanya menurunkan biayanya.

#Abstraction Layer yang Umum

• Kubernetes — abstraksi runtime: container yang sama jalan di EKS/GKE/AKS. Tapi service ekosistem (storage, IAM, observability) tetap berbeda.
• Terraform/OpenTofu — abstraksi provisioning: konfigurasi multi-provider dalam satu sintaks (episode 11).
• OpenTelemetry — abstraksi telemetry: satu pipeline observability lintas backend (episode 10).

provider "aws" {
  region = "ap-southeast-1"
}
 
provider "google" {
  project = "my-project"
}
 
resource "aws_s3_bucket" "shared" {
  bucket = "artifacts"
}
 
resource "google_storage_bucket" "shared" {
  name = "artifacts"
  location = "ASIA-SOUTHEAST-1"
}

Abstraction ini berharga bukan untuk "pindah cepat", melainkan karena satu cara berpikir untuk banyak platform — mengurangi beban kognitif dan operasional.

#Trade-off Abstraction

Setiap abstraction layer mengorbankan sesuatu: kemampuan memakai fitur khusus provider, kedalaman tuning, dan kemudahan debugging. Keputusan arsitektur: gunakan abstraction untuk lapisan yang stabil (provisioning, runtime), hindari untuk yang memanfaatkan kekuatan vendor (managed AI, serverless spesifik).

#Vendor Trade-offs dalam Praktik

Kesimpulan yang seimbang: satu provider sebagai basis, multi-cloud hanya untuk kebutuhan nyata, abstraction layer di lapisan yang stabil. Ini pola paling sehat untuk mayoritas organisasi.

#Praktik: Mendesain Hybrid/Multi-Cloud

Kerangka desain:

1. Tuliskan kebutuhan nyata (regulatory, best-of-breed, redundancy) — jika kosong, berhenti di sini.
2. Tentukan satu provider dominan untuk basis workload.
3. Identifikasi workload yang benar-benar butuh vendor kedua; sisanya tetap di basis.
4. Pakai Kubernetes + Terraform + OTel sebagai abstraction untuk lapisan yang stabil.
5. Untuk hybrid: private link primary + VPN failback, dengan security menyeluruh.
6. Dokumentasikan alasan di ADR — keputusan vendor adalah keputusan jangka panjang.

#Penutup

Inti yang harus dibawa pulang:

• Hybrid = cloud + on-premise dengan private link + VPN failback.
• Multi-cloud membawa biaya ganda; hanya layak dengan kebutuhan nyata (regulatory, best-of-breed).
• Portabilitas = seberapa murah pindah, bukan "gratis pindah".
• Abstraction layer (K8s, Terraform, OTel) menstandarkan lapisan yang stabil.
• Satu provider dominan + multi-cloud selektif + abstraction = pola paling sehat.

Di episode 17 selanjutnya kita akan membahas AI & ML architecture — workload GPU, managed ML pipelines, dan RAG/LLM. Sampai jumpa di episode 17!