Belajar DevOps Engineer - Multi-Cloud & Hybrid

#Pendahuluan

Di episode 12 kalian memilih satu penyedia cloud dan menguasainya. Sekarang muncul pertanyaan yang semakin sering diajukan: haruskah kita memakai banyak cloud sekaligus? Multi-cloud dan hybrid adalah dua strategi yang menarik — dan penuh jebakan.

Perlu diluruskan sejak awal: multi-cloud bukan tujuan. Ia adalah jawaban atas kebutuhan nyata — menghindari ketergantungan (vendor lock-in), memanfaatkan keunggulan regional, atau kepatuhan data. Jika kalian tidak punya alasan itu, satu cloud yang dikuasai penuh lebih baik daripada dua cloud yang setengah dikuasai. Episode ini membahas kapan strategi ini masuk akal, bagaimana membuat workload portabel, dan bagaimana merancang deployment lintas cloud yang realistis.

#Multi-Cloud vs Hybrid

Dua istilah yang sering tertukar:

Keduanya sama-sama menuntut portabilitas — kemampuan memindahkan workload antar-lokasi tanpa menulis ulang. Dan di sinilah seluruh praktik yang kalian pelajari selama series ini menjadi berharga: IaC, container, Kubernetes, GitOps, dan OpenTelemetry adalah bahan-bahan portabilitas.

#Lapisan Portabilitas

Workload menjadi portabel bukan karena sihir, melainkan karena abstraksi di setiap lapisan:

Contohnya: sebuah Deployment Kubernetes yang berjalan di EKS (AWS), GKE (GCP), dan AKS (Azure) — bahkan di cluster on-prem — adalah manifest yang sama. Yang berubah hanyalah tempatnya berjalan.

#Membangun Infra yang Cloud-Agnostic

Dengan Terraform, perbedaan provider dienkapsulasi dalam modul. Satu modul "web-server" dipanggil untuk tiap cloud, dengan nilai provider yang berbeda:

module "web_aws" {
  source         = "./modules/web-server"
  providers      = { aws = aws.primary }
  name           = "web-prod"
  region         = "ap-southeast-1"
}
 
module "web_gcp" {
  source         = "./modules/web-server"
  providers      = { google = google.primary }
  name           = "web-prod"
  region         = "asia-southeast1"
}

Catatan penting: abstraksi tidak gratis. Setiap provider punya perbedaan perilaku — instance type yang berbeda, IAM yang berbeda, layanan yang tidak persis sama. Kunci desainnya adalah memakai fitur bersama (intersection of features), bukan fitur paling kaya dari satu vendor.

#Strategi Hybrid: On-Prem + Cloud

Hybrid biasanya lahir dari kebutuhan nyata: data yang harus tetap di lokasi (regulasi), workload legacy yang sulit dipindah, atau kebutuhan kapasitas musiman. Pola yang umum:

• Bursting — kapasitas on-prem yang hampir penuh "meluap" ke cloud saat puncak.
• Disaster recovery — on-prem sebagai primary, cloud sebagai lokasi failover (episode 20).
• Tiering data — data panas di on-prem, arsip di cloud.

Bagi DevOps Engineer, tantangan hybrid adalah konsistensi: dua lokasi, satu cara kerja. Di sinilah Kubernetes multi-cluster dan GitOps berbicara bahasa yang sama di kedua sisi.

#Praktik: Merancang Deploy Lintas Cloud

Rancangan realistis yang bisa kalian terapkan, mulai dari skala kecil:

1. Mulai dari satu lapisan portabel — misal aplikasi di K8s yang sama di dua cloud untuk DR (primary aktif, secondary standby).
2. Satu manifest GitOps — cluster mana pun menarik dari repo yang sama; perbedaan hanya pada nilai values (endpoint, region).
3. Observability tersentralisasi — semua telemetry ke satu backend via OpenTelemetry, sehingga membandingkan kinerja antar-cloud jadi mungkin.
4. Jangan abstraksi storage global — data besar (database, object storage) biasanya tetap di satu tempat; hanya layer stateless yang dipindah antar-cloud.
5. Ukur manfaatnya — tulis alasan bisnisnya: DR? Biaya? Kepatuhan? Jika alasannya kabur, proyeknya juga akan kabur.

[ ] Alasan bisnis tertulis (DR / biaya / kepatuhan)
[ ] Workload stateless yang portabel (K8s + manifest GitOps)
[ ] Data tetap di lokasi yang dipilih dengan sengaja
[ ] Observability satu backend (OTel)
[ ] Identitas per-cloud dikelola IAM masing-masing
[ ] Tagging biaya konsisten (episode 22)
[ ] Runbook failover antar-cloud diuji (episode 20)

#Pitfall Umum

• Multi-cloud tanpa alasan — biaya kompleksitas dua kali lipat tanpa nilai yang terukur.
• Menggunakan fitur paling spesifik tiap vendor — abstraksi runtuh; workload tidak bisa dipindah tanpa ditulis ulang.
• Menganggap data bisa berpindah semudah kode — pindah data antar-cloud itu proyek besar; desain data placement sejak awal.
• Identitas yang terpecah — pastikan IAM setiap cloud dikelola dengan prinsip yang sama (episode 12).
• Melupakan observability lintas-cloud — tanpa satu lensa telemetry, perbandingan kinerja antar-cloud adalah mitos.

#Penutup

Inti yang harus dibawa pulang:

• Multi-cloud = keputusan bisnis (DR, biaya, kepatuhan), bukan teknologi untuk dinikmati.
• Portabilitas dibangun dari abstraksi: Terraform, Kubernetes, GitOps, OpenTelemetry.
• Hybrid menggabungkan on-prem dan cloud untuk kebutuhan nyata — bursting, DR, tiering.
• Desain yang benar: satu cloud dulu, lalu abstraksi — dan manfaatnya ditulis serta diukur.

Di episode 25 selanjutnya kita masuk ke Performance & Reliability — load testing dengan k6, SLO dan error budget, serta chaos engineering dasar. Semua strategi yang kalian desain di episode 24 kini diuji: apakah sistem benar-benar mampu?