Belajar Solution Architect - Hybrid & Migration Solutions

#Pendahuluan

Setelah di episode 11 kalian menguasai komunikasi stakeholder — dari pemetaan audiens sampai negosiasi trade-off — kita masuk Fase 3 dengan topik yang mendominasi agenda enterprise tahun-tahun ini: migrasi dan solusi hybrid. Hampir tidak ada perusahaan besar yang berada di satu dunia; mereka hidup dengan sistem lama on-premise bersama aplikasi baru di cloud, dan SA-lah yang merancang cara keduanya bekerja sebagai satu kesatuan.

Mengapa topik ini sulit? Karena migrasi adalah operasi dengan risiko tinggi pada sistem yang sedang menghasilkan uang. Salah langkah bukan sekadar gagal deploy — ia bisa melumpuhkan operasional harian. Maka pendekatannya harus bertahap, terukur, dan selalu punya jalan mundur.

#Kerangka 6R: Menentukan Nasib Tiap Aplikasi

Langkah pertama setiap migrasi adalah inventarisasi: daftar semua aplikasi, lalu tetapkan strateginya. Kerangka standar industri adalah 6R:

R	Arti	Kapan Dipilih	Usaha
Rehost ("lift & shift")	Pindahkan apa adanya ke VM cloud	Deadline cepat, aplikasi stabil, skill terbatas	Rendah
Replatform	Pindah + optimasi ringan (managed DB, container)	Ingin manfaat cloud tanpa ubah kode	Sedang
Repurchase	Ganti dengan SaaS	Fungsinya komoditas (CRM, HRIS, email)	Sedang
Refactor / Re-architect	Ubah arsitektur secara signifikan	Aplikasi inti, butuh skala/agility cloud penuh	Tinggi
Retire	Matikan	Tak terpakai atau tergantikan	Minimal
Retain	Biarkan on-premise	Regulasi, latensi hardware, ROI refactor buruk	Nol

Kesalahan klasik adalah memaksakan satu R untuk semua. Realita portofolio tipikalnya bercampur: 60% rehost/replatform untuk cepat pindah, 20% retire (inventaris hampir selalu mengejutkan banyaknya aplikasi zombie), sebagian kecil refactor untuk sistem yang benar-benar memberi nilai diferensiasi.

Tip

Sebelum memutuskan R mana pun, hitung TCO-nya di kedua dunia (episode 9). Banyak aplikasi internal low-traffic ternyata lebih murah dipertahankan on-premise daripada dimigrasikan — dan itu keputusan yang sah.

#Konektivitas Hybrid

Solusi hybrid berdiri di atas jalur yang andal antara data center dan cloud. Dua opsi utama:

100%

Perbandingannya:

Site-to-Site VPN — lewat internet dengan enkripsi IPsec. Setup cepat (hari), biaya rendah, bandwidth dan latency bergantung jalur publik. Cocok untuk awal migrasi, environment non-produksi, traffic moderat.
Dedicated connection (AWS Direct Connect, Azure ExpressRoute, GCP Interconnect) — jalur privat fisik ke provider. Bandwidth terjamin, latency stabil, cocok untuk produksi hybrid serius. Setup berminggu-minggu dan biaya bulanan tetap.

Praktik desain yang benar untuk hybrid production: dua jalur berbeda karakter (dedicated + VPN sebagai backup) agar kegagalan satu media tidak memutus bisnis. Jangan lupa DNS hybrid — resolusi nama lintas dua dunia adalah sumber bug integrasi paling siluman; gunakan DNS forwarding dua arah dan sepakati domain konvensi sejak awal.

#Merancang Gelombang Migrasi

Migrasi besar tidak pernah sekaligus — ia dibagi menjadi waves berdasarkan dependensi dan risiko:

Wave 0 — fondasi: landing zone (account/subscription structure), network, IAM, logging, cost tagging. Semua wave berikutnya berdiri di atas ini.
Wave 1 — pilot: aplikasi internal berisiko rendah (misal wiki internal, tool QA). Tujuannya bukan nilainya, melainkan menguji proses dan membangun muscle memory tim.
Wave 2-N — gelombang produksi: urutkan berdasarkan dependensi (panggil dulu yang dipanggil), dampak bisnis, dan kesiapan tim. Satu wave = 4-8 minggu, ditutup retro sebelum wave berikutnya.
Wave akhir — decommission: matikan infrastruktur lama resmi. Wave yang tak pernah tamat karena "takut matikan server lama" adalah pemborosan ganda (bayar dua tempat).

Untuk tiap aplikasi dalam wave, siapkan runbook migrasi: langkah persiapan, cutover, verifikasi, rollback. Rollback bukan opsional — tulis eksplisit apa yang dilakukan jika cutover gagal jam 2 pagi.

#Strategi Data Migration

Data adalah bagian tersulit dari migrasi. Pola yang lazim:

Offline — stop aplikasi, dump-restore, verifikasi, nyalakan. Sederhana, cocok untuk downtime window yang dapat diterima.
Online dengan replikasi — replikasi kontinu (AWS DMS, Azure Database Migration Service, alat CDC dari episode 7): sinkronkan dulu, potong trafik saat gap mendekati nol. Untuk database besar dengan toleransi downtime menit, inilah standar.
Strangler pattern untuk aplikasi: route trafik bertahap dari monolith lama ke service baru per fitur (via gateway), sambil modul baru dibangun di cloud. Aplikasi tua "tercekik" perlahan tanpa big-bang rewrite — pola modernization paling realistis yang kita pakai lagi di episode 13 dan 20.

Checklist cutover database (potongan runbook)

T-7 hari : replikasi online aktif, lag dipantau < 5 detik
T-1 hari : dry-run cutover di staging, rollback diuji nyata
T-0      : freeze tulis -> tunggu lag 0 -> final sync -> verifikasi
           row count & checksum sampel -> arahkan aplikasi -> smoke test
Rollback : jika smoke test gagal < 30 menit, arahkan balik ke DB lama
           (replikasi reverse aktif) -> investigasi

#Modernization yang Realistis

Setelah pindah (atau sambil hybrid), pertanyaan berikutnya: modernisasi sejauh mana? Prinsip yang menjaga kalian dari proyek abadi:

Modernize berbasis value, bukan mode — refactor hanya jika ada target terukur: biaya turun X, deploy time dari minggu ke hari, scaling untuk event tertentu.
Containerize sebagai tengah jalan — membungkus aplikasi lama ke container (tanpa rewrite total) membuka jalan ke orchestrator dan standar deployment modern dengan usaha moderat; detail strateginya di episode 14.
Managed services menggantikan pekerjaan rumah, bukan logika bisnis: ganti self-managed Kafka dengan managed streaming, ganti cron server dengan scheduler — tapi jangan biarkan vendor memutuskan logika inti kalian.
Observability duluan — sebelum menyentuh arsitektur aplikasi lama, pastikan metrik/log/tracing ada. Modernisasi tanpa observability seperti operasi tanpa monitor vital.

Warning

Waspadai "lift & shift lalu lupa": rehost tanpa rencana optimasi menghasilkan tagihan cloud yang LEBIH MAHAL dari data center lama. Rehost boleh sebagai langkah pertama, tetapi pasangkan dengan target right-sizing dan replatform di kuarter-kuarter berikutnya.

#Mengukur Sukses Migrasi

Definisikan sukses sebelum mulai, ukur setelah selesai:

Teknis: latency p95 tidak memburuk, error rate stabil, zero data loss (checksum verifikasi).
Biaya: TCO aktual vs estimasi episode 9 — bandingkan per kuartal, bukan per bulan pertama (reserved belum efektif).
Organisasi: tim mampu operasikan sendiri (runbook terpakai, on-call tanpa eskalasi ke vendor), jumlah insiden terkait migrasi = 0 mayor.
Kecepatan: waktu rilis aplikasi termigrasi naik (deploy lebih sering, batch lebih kecil).

Laporkan angka-angka ini ke sponsor dengan format status update dari episode 11 — migrasi adalah proyek yang dinilai bisnis, bukan hanya engineering.

#Penutup

Inti yang harus dibawa pulang:

Tetapkan strategi per aplikasi dengan 6R; campuran rehost/replatform/retire/retain adalah normal, refactor hanya untuk yang memberi nilai diferensiasi.
Hybrid production butuh konektiviitas berlapis: dedicated line utama, VPN cadangan, plus DNS hybrid yang dirancang sadar.
Migrasi berjalan per wave mulai dari landing zone dan pilot; setiap cutover punya runbook lengkap dengan rollback teruji.
Data bergerak via replikasi online (DMS/CDC) untuk downtime minimal; aplikasi legacy berevolusi lewat strangler pattern, bukan big-bang rewrite.
Sukses migrasi didefinisikan multi-dimensi: teknis, biaya, organisasi, kecepatan — dan dilaporkan dengan bahasa bisnis.

Di episode 13 selanjutnya kita akan membahas serverless & event solutions — kapan serverless tepat (dan kapan mahal), merancang arsitektur event-driven dengan FaaS, menghitung biayanya secara presisi, serta pola saga dan orkestrasi workflow untuk proses bisnis panjang. Sampai jumpa di episode 13!