Belajar Cloud Architect - Modernization & Legacy
Sebagian besar pekerjaan arsitek bukan membangun baru — melainkan memodernisasi sistem legacy tanpa menghentikan bisnis. Episode ini membedah strategi 6R (rehost, replatform, refactor, dll), strangler pattern untuk migrasi bertahap, dan cloud adoption framework
#Pendahuluan
Sejauh ini series ini membangun arsitektur baru. Realita di lapangan berbeda: sebagian besar pekerjaan arsitek adalah memodernisasi sistem lama — aplikasi berumur 10 tahun, database di server tua, dan dependensi yang tidak lagi terpelihara. Dan semuanya harus berubah tanpa menghentikan bisnis di prosesnya.
Episode ini membangun kemampuan modernisasi: kapan memilih strategi mana (6R), cara mengganti sistem legacy sedikit demi sedikit tanpa "big bang" (strangler pattern), dan kerangka adopsi dari provider (Cloud Adoption Framework).
#Strategi 6R: Memilih Tingkat Migrasi
#Enam Jalur
Setiap aplikasi legacy harus diputuskan satu jalurnya. Enam R yang umum:
| Strategi | Arti | Effort | Benefit |
|---|---|---|---|
| Rehost | Pindah apa adanya (lift & shift) | Rendah | Cepat, hemat jangka pendek |
| Replatform | Pindah dengan optimasi ringan (managed DB) | Sedang | Manfaat tanpa tulis ulang |
| Refactor | Tulis ulang arsitektur (modern) | Tinggi | Manfaat penuh jangka panjang |
| Repurchase | Ganti dengan SaaS | Bervariasi | Hentikan pengembangan |
| Retire | Matikan yang tidak terpakai | Rendah | Hemat langsung |
| Retain | Biarkan di tempat | Nol | Risiko ditunda |
Tip
Aturan emas: jangan refactor sebelum rehost/replatform terbukti tidak cukup. Mayoritas aplikasi mendapatkan nilai besar dari rehost + replatform (managed database, otomasi, observability) tanpa biaya tulis ulang. Refactor hanya untuk aplikasi yang benar-benar jadi beban.
#Keputusan dalam Praktik
App billing (10 tahun, dipakai semua orang)
→ Replatform: pindah VM, pakai managed DB, otomasi
App inventory (kode berantakan, sering gagal)
→ Refactor: tulis ulang dengan pola modern (episode 12)
App forms (duplikat dari tool yang sudah dibeli)
→ Repurchase: ganti dengan SaaS yang sudah ada
Server batch (tidak dipakai lagi)
→ Retire: matikan, hemat biaya langsung#Strangler Pattern: Migrasi Bertahap
#Mengapa Bukan "Big Bang"
Mengganti seluruh sistem legacy sekaligus adalah salah satu penyebab kegagalan proyek terbesar: satu kesalahan dan bisnis berhenti. Strangler pattern memilih jalur sebaliknya — potong sedikit demi sedikit: sistem baru secara bertahap mengambil alih fungsi, sistem lama mati pelan-pelan.
#Cara Kerja
Setiap iterasi: satu fitur dipindahkan dari legacy ke service baru di belakang gateway; traffic diarahkan; jika baru stabil, fitur lama dimatikan. Bisnis tidak pernah berhenti — setiap langkah kecil dan bisa di-rollback.
#Langkah-Langkah Strangler
- Petakan fungsi sistem legacy menjadi unit yang bisa dipindah satu per satu.
- Bentangkan gateway di depan sistem lama — titik kontrol untuk merutekan traffic.
- Pindahkan satu fungsi ke service baru (pola episode 12).
- Rutekan traffic fungsi itu ke service baru; bandingkan behavior.
- Matikan fungsi lama setelah stabil; ulangi untuk fungsi berikutnya.
#Kapan Strangler Cocok
- Legacy masih hidup dan dipakai — tidak bisa berhenti.
- Fungsi bisa dipisahkan secara wajar.
- Tim bisa menambah service baru sambil legacy tetap jalan.
Jika sistem terlalu terjalin untuk dipisah, strategi lain (rehost dulu, lalu strangle di lingkungan baru) lebih masuk akal.
#Cloud Adoption Framework
#Kerangka Resmi
Setiap provider punya kerangka adopsi: AWS CAF (Cloud Adoption Framework), Google Cloud Adoption Framework, Microsoft CAF. Meski berbeda nama, strukturnya sama — adopsi cloud bukan proyek teknis, melainkan perubahan di banyak lini:
| Perspektif | Pertanyaan Utama |
|---|---|
| Business | Value apa yang dicari? Bagaimana diukur? |
| People | Siapa yang menjalankan? Skill apa yang dibutuhkan? |
| Governance | Bagaimana kepatuhan & kontrol (episode 23)? |
| Platform | Bagaimana landasan cloud dibangun (landing zone)? |
| Security | Bagaimana risiko dikelola (episode 7, 19)? |
| Operations | Bagaimana sistem dioperasikan (episode 10)? |
#Landing Zone
Salah satu konsep paling penting: landing zone — fondasi cloud standar yang disiapkan sekali dan dipakai semua workload: hierarki akun, networking dasar, IAM, logging, dan security baseline (episode 18-20). Modernisasi di atas landing zone yang baik jauh lebih mudah.
#Praktik: Rencana Modernisasi Legacy
Kerangka rencana:
- Inventory semua aplikasi legacy; klasifikasi ke 6R (retire dulu — hemat cepat).
- Untuk yang dipertahankan: tentukan urutan (mulai dari yang paling bernilai & paling mudah).
- Gunakan strangler pattern untuk migrasi bertahap tanpa berhenti.
- Bangun di atas landing zone yang sudah standar (IaC, episode 11).
- Ukur kemajuan dengan metrik (cost, reliability, rilis) — bukan "sudah pindah berapa persen".
- Dokumentasikan strategi per aplikasi di ADR.
#Penutup
Inti yang harus dibawa pulang:
- Enam R: rehost/replatform untuk nilai cepat; refactor saat benar-benar perlu.
- Strangler pattern memindahkan fungsi bertahap tanpa menghentikan bisnis.
- Adopsi cloud adalah perubahan multi-lini, bukan proyek teknis.
- Landing zone menyediakan fondasi standar untuk semua workload.
- Modernisasi diukur dengan outcome, bukan persentase migrasi.
Di episode 25 selanjutnya kita akan membahas strategic & business architecture — menghubungkan arsitektur ke business outcomes, TCO, dan komunikasi dengan stakeholder. Sampai jumpa di episode 25!