Belajar Cloud Engineer - Migration to Cloud

#Pendahuluan

Sejauh ini kalian membangun aplikasi baru di cloud dari nol — menyenangkan karena tidak ada beban masa lalu. Di dunia kerja, tantangan sesungguhnya berbeda: memindahkan sistem yang sudah berjalan 10 tahun di datacenter sendiri ke cloud, tanpa menghentikan bisnis. Di sinilah reputasi seorang cloud engineer diuji.

Episode 17 membahas migration to cloud: cara menilai aplikasi (assessment), lima strategi besar yang dikenal sebagai 6R, perbedaan lift-and-shift vs re-platform, dan data migration yang aman. Kalian akan menyusun rencana migrasi untuk satu aplikasi nyata — lengkap dengan jadwal, kriteria sukses, dan rollback plan.

#Assessment: Kenali Dulu Sebelum Memindah

Kesalahan terbesar tim migrasi pemula: langsung memindahkan semuanya. Migrasi yang baik dimulai dengan assessment — memetakan aplikasi sebelum menyentuh apa pun. Data yang dikumpulkan per aplikasi:

Hasilnya adalah inventarisasi aplikasi + skor kesiapan. Aplikasi yang siap (architecturanya sederhana) masuk batch pertama; yang kompleks ditunda. Aturan penting: jangan memigrasi aplikasi yang masih berubah-ubah — migrasikan versi yang stabil, lalu lanjutkan pengembangan di cloud.

#Strategi 6R

Pilihan strategi migrasi bukan satu, melainkan enam — dan memilih dengan tepat adalah kompetensi inti:

Urutan hemat vs usaha: Retire dan Retain paling murah (mungkin bahkan tidak perlu migrasi); Refactor paling mahal tapi memberi hasil paling besar untuk aplikasi yang sedang berkembang.

#Lift-and-Shift vs Re-platform

Dua strategi yang paling sering dibandingkan:

Lift-and-shift (rehost) — VM on-prem menjadi VM cloud dengan konfigurasi serupa. Cepat (minggu), risiko kecil, tapi belum memanfaatkan apa pun dari cloud: tidak ada auto-scaling, tidak ada managed service, biaya bisa lebih tinggi daripada on-prem.

Re-platform — pindah sambil mengganti beberapa komponen:

Re-platform memberi manfaat nyata (managed backup, scaling, patching otomatis) dengan usaha sedang. Untuk aplikasi yang diharapkan bertahan 3-5 tahun, re-platform hampir selalu lebih baik daripada lift-and-shift murni.

#Data Migration

Memindahkan data adalah bagian paling berisiko — ukuran besar, downtime, dan risiko kehilangan. Pola yang benar:

1. Baseline — salin data awal (full copy).
2. Sync berkelanjutan — replikasi perubahan selama transisi (CDC / log shipping).
3. Cutover — hentikan aplikasi lama sesaat, sinkronkan perubahan terakhir, alihkan trafik.
4. Verifikasi — cek jumlah baris, checksum, dan sample query sebelum menyatakan sukses.

# 1. Full baseline ke target (DMS / Data Transfer Service)
# 2. Replikasi perubahan berkelanjutan
# 3. Cutover: hentikan app, flush sisa perubahan
# 4. Verifikasi jumlah record kedua sisi
SELECT count(*) FROM orders;   -- on-prem
SELECT count(*) FROM orders;   -- cloud (harus sama)

Untuk dataset raksasa (petabyte), ada opsi fisik: AWS Snowball / Azure Data Box / GCP Transfer Appliance — kirim hard disk berisi data ke datacenter provider, jauh lebih cepat daripada transfer internet. "Cloud" tidak selalu berarti "lewat internet".

#Praktik: Rencana Migrasi Aplikasi

Mari susun rencana migrasi untuk aplikasi lab-ecommerce (yang kita bangun sejak episode 3-5): web server di VM, PostgreSQL di server sendiri, dan cron job harian.

1. Assessment: arsitektur 3 komponen, beban trafik menengah, SLA downtime maksimal 4 jam, data 50 GB.
2. Pilih strategi: re-platform — web di VM dengan auto-scaling nanti (episode 21), database ke managed DB, cron ke function + scheduler.
3. Susun jadwal (cutover di luar jam puncak, misal Minggu 02:00):
   • Minggu 1: siapkan target (VPC, DB managed, VM, IAM).
   • Minggu 2: data migration baseline + sync.
   • Minggu 3: uji aplikasi terhadap DB baru; buat rollback plan.
   • Minggu 4: cutover, verifikasi, lalu retire VM lama.
4. Kriteria sukses: response time setara atau lebih baik, data 100% sama, tidak ada fungsi yang hilang.
5. Rollback plan: snapshot dan DNS cutover ganda — jika satu jam pertama bermasalah, kembalikan DNS ke infrastruktur lama.

cutover:
  persiapan:
    - snapshot DB sumber
    - pause cron & writer pada app lama
    - pastikan sync replication lag = 0
  eksekusi:
    - switch DNS/web ke target cloud
    - resume writer
  verifikasi:
    - healthcheck: 200 OK
    - perbandingan jumlah record DB
    - review log error 1 jam pertama
  rollback:
    - jika gagal: switch DNS kembali ke sumber
    - target ditahan (bukan dihapus) sampai stabil 48 jam

Aturan emas migrasi: rollback plan bukan opsional — jika tidak bisa dikembalikan, jangan mulai. "Tidak perlu rollback" adalah kalimat yang tidak pernah boleh diucapkan di depan cutover.

#Kesalahan Umum (Common Pitfalls)

1. Migrasi tanpa assessment — memindahkan aplikasi yang seharusnya di-retire atau di-refactor.
2. Lift-and-shift sebagai satu-satunya strategi — masalah lama hanya pindah alamat.
3. Cutover di jam sibuk — downtime bisnis maksimal; selalu pilih jendela paling sepi.
4. Tanpa rollback plan — satu kegagalan menjadi bencana; DNS ganda + snapshot adalah jaring pengaman.
5. Migrasi data tanpa verifikasi — beda satu baris pun bisa merusak laporan; selisihkan dua sisi sebelum sukses.
6. Memindahkan aplikasi yang masih aktif dikembangkan — versi bergerak yang tidak pernah stabil untuk cutover.

#Penutup

Inti yang harus dibawa pulang:

• Migrasi dimulai dari assessment, bukan dari memindahkan.
• Pilih dari 6R: Rehost, Replatform, Repurchase, Refactor, Retain, Retire — beda konteks, beda pilihan.
• Re-platform hampir selalu lebih baik daripada lift-and-shift murni untuk aplikasi jangka panjang.
• Data migration pakai pola baseline → sync → cutover → verifikasi.
• Rollback plan adalah syarat mutlak sebelum cutover apa pun.

Di episode 18 selanjutnya kita akan naik ke lapisan konektivitas antar-datacenter: cloud networking lanjutan — Transit Gateway, VPN & Direct Connect, PrivateLink, dan CDN, lalu membangun konektivitas hybrid antara cloud dan jaringan on-prem. Sampai jumpa di episode 18!