Belajar System Engineer - Hybrid & Migration

#Pendahuluan

Di episode 13 kita membangun sistem di cloud dari nol. Realita di lapangan, bagaimanapun, tidak selalu mulai dari nol: banyak perusahaan memiliki data center sendiri yang sudah berjalan bertahun-tahun, lalu ingin pindah sebagian atau seluruhnya ke cloud. Di sinilah peran System Engineer diuji: migrasi.

Mengapa episode ini penting? Migrasi adalah proyek dengan risiko paling tinggi — melibatkan data, downtime, dan harapan bisnis yang besar. Kesalahan perencanaan berarti data hilang, aplikasi turun lama, atau pengguna akhir terkena dampak. Episode ini membekali kalian kerangka berpikir: kapan dan mengapa migrasi, strategi yang tersedia, perencanaan jaringan hybrid, dan eksekusi yang aman.

#Kapan dan Mengapa Migrasi?

Sebelum mulai, pahami mengapa — bukan sekadar karena tren. Motivasi umum:

Motivasi	Pertimbangan
Biaya	Cloud bisa lebih murah (atau lebih mahal!) — hitung TCO dengan jujur
Skalabilitas	Beban naik-turun, butuh elastisitas
Modernisasi	Memanfaatkan managed services & automation
Bencana	Butuh DR site yang terkelola

Tidak semua workload cocok dipindah. Aplikasi dengan latensi sangat rendah antar-komponen, atau yang terikat hardware khusus, bisa tetap di on-prem. Hasil analisis ini disebut workload assessment — hasilnya menentukan strategi.

#Strategi Migrasi: The 7 R's

Strategi	Arti	Contoh
Rehost (lift-and-shift)	Pindahkan apa adanya	VM on-prem → EC2
Replatform	Ubah sedikit agar cocok cloud	Postgres self-managed → RDS
Repurchase	Ganti dengan SaaS	CRM custom → Salesforce
Refactor/Re-architect	Bangun ulang agar cloud-native	Monolit → microservices
Relocate	Pindah ke cloud lain	AWS → GCP
Retain	Biarkan tetap on-prem	Aplikasi terikat hardware
Retire	Matikan yang tidak terpakai	Server ghost

100%

Prinsipnya: pilih strategi paling sederhana yang memenuhi tujuan. Rehost lebih cepat dan murah risikonya; refactor paling mahal dan berisiko — hanya lakukan jika benar-benar dibutuhkan.

#Jaringan Hybrid

Selama migrasi bertahap, cloud dan on-prem harus berkomunikasi seolah-olah satu jaringan. Solusi konektivitas hybrid:

VPN Site-to-Site — tunnel terenkripsi antara data center dan VPC (mudah, bandwidth terbatas).
Direct Connect / PrivateLink — koneksi private berdedikasi (latensi stabil, biaya lebih tinggi).

Di AWS, koneksi on-prem ke VPC memungkinkan on-prem mengakses resource privat cloud:

100%

Perencanaan alamat IP harus hati-hati: hindari overlap CIDR antara on-prem dan cloud — dua jaringan dengan 10.0.0.0/8 tidak bisa di-bridge tanpa NAT yang rumit.

#Eksekusi Migrasi yang Aman

#Perencanaan

Sebelum mengeksekusi, jawab pertanyaan-pertanyaan berikut dan tulis di dokumen (episode 2):

Urutan migrasi: komponen mana yang duluan? (paling tidak kritis dulu)
Jendela migrasi: kapan trafik terendah? Kapan persetujuan bisnis?
Strategi cutover: cutover penuh, atau bertahap (blue/green, 10% trafik)?
Rollback plan: bagaimana kembali jika gagal? Apa sinyal untuk rollback?
Validasi: bagaimana memastikan aplikasi berfungsi sama setelah pindah?

#Contoh: Migrasi Database on-prem → RDS

Langkah migrasi database

# 1. Setup target RDS + security group (akses dari aplikasi)
# 2. Ekspor dari sumber
pg_dump -h 10.0.3.11 -U appuser -d appdb -Fc -f appdb.dump
 
# 3. Restore ke RDS
pg_restore -h rds-host.region.rds.amazonaws.com -U appuser -d appdb appdb.dump
 
# 4. Validasi data
psql -h rds-host... -U appuser -d appdb -c "SELECT count(*) FROM users;"
 
# 5. Cutover: ubah konfigurasi aplikasi menunjuk ke RDS
# 6. Jika gagal: kembalikan konfigurasi ke on-prem (rollback)

#Prinsip Eksekusi

Backup sebelum dan sesudah — migrasi selalu mulai dari data yang terverifikasi.
Satu perubahan per langkah — jangan sekaligus pindah + upgrade + ubah arsitektur.
Rollback tersedia setiap saat — sampai validasi final, jalan pulang harus terbuka.
Dokumentasikan durasi tiap langkah — menjadi data untuk migrasi berikutnya.

Tip

Praktik terbaik migrasi: migrasi paralel (fase ganda). Jalankan sistem baru dan lama berdampingan, sinkronkan datanya, lalu alihkan trafik bertahap. Dengan cara ini, kegagalan di sistem baru tidak memutus pengguna — cukup kembali ke sistem lama. Lebih lambat, tapi jauh lebih aman daripada "big bang" sekali pindah.

#Praktik: Rencana Migrasi

Buat dokumen rencana migrasi untuk studi kasus sederhana (aplikasi web + database):

Rencana Migrasi: app-web

# Rencana Migrasi app-web (on-prem -> AWS)
## 1. Assessment
   - Beban: 5k request/menit, puncak pagi
   - Keputusan: Replatform (web -> EC2, DB -> RDS)
## 2. Target
   - EC2 t3.large x2 (subnet privat, ALB di depan)
   - RDS PostgreSQL (multi-AZ) di subnet privat DB
## 3. Jaringan
   - VPN site-to-site; CIDR cloud 10.100.0.0/16 (tanpa overlap)
   - Security group: 443 dari ALB, 5432 hanya dari EC2 app
## 4. Urutan & jadwal
   - M1: setup VPC, VPN, RDS
   - M2: deploy app baru, sync data, validasi
   - M3: cutover DNS 10% -> 50% -> 100%
## 5. Rollback
   - Kembalikan DNS ke on-prem; data tetap berjalan
## 6. Validasi
   - Checklist fungsi, performa, monitoring alert aktif

#Kesalahan Umum

Langsung rehost tanpa assessment — workload yang tidak cocok cloud malah lebih mahal dan lambat.
Overlap CIDR on-prem & cloud — jaringan hybrid tidak bisa di-route dengan mudah.
Big bang tanpa rollback plan — kegagalan = downtime panjang.
Migrasi sambil upgrade sekaligus — terlalu banyak variabel, sulit di-debug.
Tidak validasi performa setelah pindah — sistem baru "jalan" tapi lebih lambat dari rencana.

#Penutup

Inti yang harus dibawa pulang:

Pahami motivasi migrasi dan lakukan workload assessment dulu.
Pilih dari 7 R's — paling sederhana yang memenuhi tujuan; rehost dulu, refactor terakhir.
Jaringan hybrid butuh VPN/Direct Connect dan CIDR yang tidak overlap.
Eksekusi: urutan jelas, cutover bertahap, rollback tersedia, validasi di tiap langkah.

Di episode 15 selanjutnya kita mengelola salah satu platform paling dominan saat ini: Kubernetes system ops — operasional cluster, node management, dan workloads. Sampai jumpa di episode 15!