Belajar Cloud Engineer - Multi-Cloud & Hybrid Architecture

#Pendahuluan

Sejak episode 0, kalian mengerjakan satu provider — keputusan yang tepat untuk belajar. Tapi di industri, pertanyaan "mengapa tidak pakai dua provider?" semakin sering muncul. Ada perusahaan yang menempatkan beban produksi di AWS dan cadangan di GCP; ada yang memakai AWS untuk data di Asia dan Azure untuk layanan Office; ada yang memakai multi-cloud hanya karena tidak mau bergantung pada satu vendor.

Episode 22 membahas multi-cloud & hybrid architecture: apa yang sebenarnya diperoleh (dan dibayar) dari multi-cloud, bagaimana Terraform multi-provider membuat infrastruktur konsisten lintas cloud, dan strategi hybrid yang menggabungkan beberapa cloud serta on-prem. Kalian akan membangun infrastruktur yang berjalan di dua cloud sekaligus dari satu basis kode.

#Mengapa Multi-Cloud (dan Mengapa Tidak)

Jujur dulu: multi-cloud bukan default yang harus dipaksakan. Keuntungannya nyata, tapi biayanya juga nyata.

Keuntungan:

1. Avoid vendor lock-in — tidak semua kemampuan di semua provider; fleksibilitas negosiasi harga.
2. Resilience — kegagalan satu provider tidak menjatuhkan semua workload (episode 20 DR lintas region diperluas lintas provider).
3. Best-of-breed — pakai kekuatan masing-masing: ML di GCP, global reach di AWS, integrasi Microsoft di Azure.

Biaya:

1. Kompleksitas operasional — dua console, dua IAM, dua model billing, dua SLA.
2. Jaringan antar-cloud — trafik antar-provider mahal dan berlatensi.
3. Tim harus menguasai dua ekosistem — kurva belajar ganda.

#Portabilitas: Kunci Multi-Cloud yang Sehat

Multi-cloud yang baik adalah multi-cloud yang portabel — kode, konfigurasi, dan data bisa dipindah antar-provider tanpa ditulis ulang. Prinsipnya:

1. IaC multi-provider (Terraform/OpenTofu) — infrastruktur diekspresikan sekali, diterjemahkan ke banyak cloud.
2. Container sebagai unit deploy — aplikasi berjalan identik di EKS, GKE, maupun AKS (episode 10, 12).
3. Hindari managed service yang mengunci — jangan gantung aplikasi pada fitur yang tidak ada di provider lain (contoh: memakai DynamoDB sambil berencana pindah ke GCP tanpa adaptasi).
4. Abstraksi lapisan — pisahkan lapisan yang portabel (compute, storage) dari yang tidak (managed AI, proprietary messaging).

Kisaran realita: aplikasi container + object storage + PostgreSQL bersifat portabel dengan usaha sedang; memakai Amazon Aurora + DynamoDB + Kinesis mengikat kalian ke AWS cukup dalam.

#Terraform Multi-Provider

Kekuatan Terraform (episode 7) yang paling terasa di multi-cloud: satu workflow, banyak provider. Ia bisa mengelola resource AWS dan GCP dalam satu state — bahkan membangun konektivitas di antara keduanya.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
}
 
provider "aws" {
  region = "ap-southeast-1"
}
 
provider "google" {
  project = "lab-multicloud"
  region  = "asia-southeast2"
}

Dengan ini, satu terraform apply bisa membuat VM di AWS dan VM di GCP sekaligus:

resource "aws_instance" "web_aws" {
  ami           = "ami-0a1b2c3d"
  instance_type = "t3.micro"
  tags = { Name = "web-aws" }
}
 
resource "google_compute_instance" "web_gcp" {
  name         = "web-gcp"
  machine_type = "e2-micro"
  zone         = "asia-southeast2-a"
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
    }
  }
}

Konsistensi ini bukan kebetulan — keduanya memakai pola yang sama (resource, argument, referensi antar-resource) dengan sintaks yang sama. Kalian belajar sekali, dipakai di mana-mana. Ada juga module komunitas yang menstandardisasi satu abstraksi (misal terraform-aws-modules/vpc) ke beberapa provider — atau yang lebih umum, kalian menulis module sendiri yang mengekspresikan "satu aplikasi" lintas cloud.

#Strategi Hybrid

Hybrid bisa berarti beberapa hal; ketiganya punya bentuk yang berbeda:

Untuk cloud + on-prem, konektivitas yang dibangun di episode 18 (VPN/Direct Connect) menjadi fondasinya; untuk dua cloud, site-to-site VPN antar-provider atau Interconnect membuat jaringan keduanya saling melihat. Perlu diingat: trafik antar-provider dikenai egress di kedua sisi — mahal dan berlatensi, sehingga komunikasi antar-cloud harus hemat (pakai queue/streaming yang sudah dibahas di episode 13, bukan panggilan sinkron berlebihan).

#Praktik: Infrastruktur Lintas Cloud

Mari bangun versi kecil infrastruktur multi-cloud yang nyata:

1. Siapkan kedua provider — pastikan aws dan gcloud login, kredensial Terraform tersedia (episode 0, 7).
2. Tulis main.tf dengan provider ganda (di atas).
3. Buat resource serupa — VM di AWS dan VM di GCP, plus bucket di keduanya.
4. Kelola state bersama — satu backend (misal S3 atau GCS) untuk kedua provider; ingat remote state episode 7.
5. Verifikasi: terraform plan menampilkan resource di dua cloud, terraform apply menjalankannya, terraform destroy membersihkan keduanya.
6. Refleksi: apa yang mudah dipindahkan? Apa yang terasa vendor-specific? Itu peta portabilitas kalian.

terraform init
terraform plan    # resource AWS + GCP dalam satu plan
terraform apply -auto-approve
terraform state list | sort   # daftar semua resource lintas provider

Pengalaman mengerjakan satu state yang berisi dua cloud inilah yang membedakan kalian dari sekadar "orang yang bisa klik dua dashboard".

#Kesalahan Umum (Common Pitfalls)

1. Multi-cloud tanpa alasan — kompleksitas ganda tanpa manfaat nyata; mulailah single-cloud.
2. Lapisan aplikasi terikat managed service — memakai fitur eksklusif provider sambil berencana multi-cloud.
3. State Terraform terpisah-pisah — resource AWS dan GCP tidak saling tahu; satu state/workspace yang rapi.
4. Mengabaikan biaya egress antar-cloud — trafik antar-provider bikin tagihan membengkak (episode 16).
5. IAM terpisah tanpa standar — pola akses berbeda di tiap cloud; definisikan satu model konseptual (episode 6, 19).
6. Menganggap multi-cloud = DR otomatis — DR lintas provider tetap butuh replikasi, runbook, dan drill (episode 20).

#Penutup

Inti yang harus dibawa pulang:

• Multi-cloud memberi fleksibilitas dan resilience, tapi dengan biaya kompleksitas — mulai single-cloud, perluas dengan alasan.
• Portabilitas datang dari IaC, container, dan abstraksi lapisan — bukan dari doa.
• Terraform multi-provider memungkinkan satu workflow, satu state, dua (atau lebih) cloud.
• Hybrid mencakup cloud+on-prem, dua cloud aktif, dan DR lintas provider.
• Ketahui peta portabilitas aplikasi kalian — apa yang mudah dan apa yang mengikat.

Di episode 23 selanjutnya kita akan memasuki topik yang sedang memuncaki setiap roadmap 2026: AI & ML services cloud — managed ML (SageMaker/Vertex AI), AI APIs, dan GPU workloads, lalu men-deploy model di cloud. Sampai jumpa di episode 23!