Belajar Enterprise Architect - Cloud & Hybrid Enterprise
Merumuskan cloud strategy tingkat enterprise: kerangka migrasi 6R, mendesain landing zone multi-account, mengelola multi-cloud tanpa biaya ganda, dan menempatkan workload teregulasi BayarKu dalam arsitektur hybrid yang lolos regulator
#Pendahuluan
Setelah di episode 12 ketiga lini Bumi Niaga terhubung lewat API gateway dan event backbone, pertanyaannya berpindah ke fondasi fisik: di mana semua itu berjalan dan ke mana kita membawanya? Episode ini tentang enterprise cloud strategy — pekerjaan yang jauh lebih luas daripada "migrasi ke cloud": keputusan portofolio (workload mana ke mana), desain landing zone, pengelolaan multi-cloud, dan penempatan workload teregulasi dalam model hybrid.
Ingat diagnosis episode 7: Bumi Niaga dalam kondisi multi-cloud by accident — AWS, GCP, dan on-premise lahir dari keputusan lokal, tanpa strategy. Sekarang kita merumuskan strategy-nya dengan alat yang benar.
#Kerangka Migrasi: 6R
Standar industri untuk memutuskan nasib tiap aplikasi saat bergerak ke cloud adalah enam R — dan kuncinya, bukan semua aplikasi layak dimigrasi:
| R | Arti | Kapan Dipilih | Contoh Bumi Niaga |
|---|---|---|---|
| Rehost | Lift-and-shift apa adanya | Butuh keluar DC cepat; aplikasi sehat | Aplikasi internal HR ke IaaS |
| Replatform | Upgrade minor di tengah jalan | Manfaat managed service murah | DB Oracle ke PostgreSQL managed |
| Refactor | Ubah arsitektur untuk native cloud | Nilai bisnis besar, health buruk | Monolith checkout BelanjaKu |
| Repurchase | Ganti dengan SaaS | Fungsi komoditas | Email, HRIS, ITSM |
| Retire | Matikan | Tak dipakai | Hasil disposisi TIME ep 6 |
| Retain | Biarkan di tempat | Regulasi, ROI negatif, segera mati | Core ledger BayarKu |
Dua kesalahan eksekusi yang paling mahal. Pertama, rehost massal tanpa analisis: biaya cloud justru naik dibanding DC karena infrastruktur lama direplikasi mentah — lift-and-shift sah untuk kecepatan, tapi harus sadar bahwa optimasi datang belakangan. Kedua, refactor serba-serba: refactor adalah opsi termahal; diajarkan hanya untuk aplikasi Invest dari matriks TIME, sisanya cukup replatform atau rehost.
Latihan portofolio: ambil inventaris episode 6, tempelkan R pada tiap aplikasi, lalu hitung kasar biaya dan durasi tiap R — hasilnya biasanya mengejutkan: separuh anggaran migrasi habis untuk aplikasi bernilai rendah yang seharusnya retire atau repurchase ke SaaS.
#Landing Zone Multi-Account: Fondasi Skala
Strategy tanpa fondasi menghasilkan cloud kedua yang sama kacau dengan yang pertama. Fondasi modernnya landing zone multi-account (AWS) atau multi-project/folder (GCP):
- Struktur akun per fungsi — production/nonprod terpisah per unit atau per domain; blast radius insiden dan izin akses terbatas per akun.
- Baseline otomatis — network hub-spoke, IAM federasi ke IdP grup (episode 7), logging sentral, tagging wajib, guardrail policy-as-code.
- Self-service untuk tim — tim produk memesan environment baru lewat pipeline/template, bukan tiket ke tim infrastruktur. Ini pembeda landing zone sukses: ia percepat, bukan mengantrekan.
Anggaran waktu yang realistis: landing zone pertama adalah program 2-3 bulan dengan tim platform kecil — investasi yang membayar dirinya saat workload kesepuluh onboard. Tanpa itu, tiap tim membangun VPC, IAM, dan logging versinya sendiri: itulah biaya sesungguhnya dari "biarkan tiap tim bebas".
#Mengelola Multi-cloud Tanpa Bangkrut
Realita: ketiga provider akan tinggal untuk sementara. Strategy yang tepat bukan ilusi "portable everywhere", melainkan manajemen kompleksitas yang disiplin:
- Standardisasi di layer yang bisa distandarkan — Kubernetes API, Terraform/OpenTofu untuk IaC, OpenTelemetry untuk observability, IdP tunggal. Skill dan tooling berpindah lintas provider; inilah portability praktis, bukan mimpi tuliskode-sekali-jalan-di-mana-pun.
- Data gravitasi dihormati — data besar ditempatkan dekat compute yang memprosesnya; egress lintas cloud untuk traffic berat adalah pemborosan struktural. Event backbone (episode 12) boleh cross-cloud untuk fakta bisnis, bukan untuk replikasi dataset massal.
- Satu operasi, dua provider — monitoring dan billing digabung di level grup; kalau tiap provider punya dashboard biaya dan alert sendiri yang tak bicara, FinOps (episode 15) mustahil.
Important
Uji keputusan multi-cloud: setiap provider tambahan harus punya justifikasi workload eksplisit dan estimasi biaya kompleksitas (skill ganda, security ganda). Provider tanpa justifikasi adalah kandidat konsolidasi di momen renewal — bukan warisan abadi.
#Hybrid yang Lolos Regulator: Kasus BayarKu
Workload teregulasi fintech adalah kasus hybrid paling menarik. Posisinya bukan "on-premise selamanya" maupun "migrasi total", melainkan segmentasi sadar-regulasi:
Pola yang berlaku umum: data dan komputasi yang disebut regulasi tetap di fasilitas milik/kendali; layer channel dan API publik boleh di cloud untuk elastisitas; komunikasi lewat private interconnect; dan setiap aliran keluar data teregulasi (biasanya agregat/anonim) punya dasar persetujuan compliance yang terdokumentasi. Detail regulasinya kita bongkar di episode 19 — hari ini cukup dipahami bahwa hybrid by design untuk compliance adalah pola sah, berbeda dengan hybrid by accident.
Metrik kesehatan cloud yang layak dilaporkan bulanan: persentase workload di landing zone vs liar, coverage tagging biaya, jumlah akun/proyek tanpa owner, dan utilisasi committed discount. Angka terakhir itu pintu masuk episode FinOps.
#Anti-Pattern Multi-Cloud yang Sering Terjadi
| Anti-Pattern | Gejala | Obat |
|---|---|---|
| Replikasi dataset massal lintas provider | Tagihan egress membengkak tiap bulan | Data gravitasi + sinkronisasi lewat event agregat |
| Skill silo per provider | On-call tak bisa saling menggantikan | Standardisasi layer atas (K8s, IaC, OTel) |
| Security model berbeda per cloud | Audit ganda, celah konsistensi policy | IdP tunggal + guardrail seragam di landing zone |
| Tooling native dipakai mentah-mentah | Tiap workload jadi vendor-specific | Abstraksi hanya untuk layer yang berpindah-pindah |
Ilustrasi data gravity dengan angka: dataset klikstream BelanjaKu 40 TB di AWS yang diproses harian oleh cluster analitik di GCP akan membayar egress puluhan ribu dolar per bulan plus latency tambahan — sekadar agar "semua data ada di satu tempat". Aturan praktisnya selalu: compute mengikuti data; kolaborasi lintas lini terjadi lewat event fakta dan agregat (episode 12), bukan replikasi raw.
#Praktik: Cloud Strategy Bumi Niaga
Kerjakan di ea-lab/case-study/technology/cloud-strategy.md:
- Penetapan 6R — tabel semua aplikasi signifikan dari episode 6 dengan R-nya plus justifikasi satu baris; hitung proporsi rehost/refactor/retire.
- Desain landing zone — struktur akun/proyek untuk AWS dan GCP, network hub, baseline IAM/logging/tagging, alur self-service onboarding tim.
- Aturan multi-cloud — tiga aturan standardisasi layer dan dua aturan data gravitasi, format prinsip episode 9.
- Skema hybrid BayarKu — lengkapi diagram di atas dengan keputusan data apa yang boleh keluar sebagai agregat dan kontrol apa yang menyertainya.
#Penutup
Inti yang harus dibawa pulang:
- Migrasi diputuskan per aplikasi lewat 6R dengan biaya-durasi eksplisit; rehost untuk kecepatan, refactor hanya untuk aplikasi Invest, dan retire/repurchase sering jadi pemenang yang terabaikan.
- Landing zone multi-account dengan self-service adalah fondasi yang membuat cloud strategy terwujud di workload ke-10, ke-50, dst.
- Multi-cloud dikelola lewat standardisasi layer atas (K8s, IaC, OTel, IdP), data gravitasi, dan konsolidasi operasi — bukan lewat ilusi portability penuh.
- Hybrid untuk compliance seperti BayarKu adalah pola sah: core teregulasi on-prem, channel di cloud, aliran data terkontrol dan terdokumentasi.
Fondasi beres. Di episode 14 kita naik ke lapisan yang melintasi semuanya: security & compliance architecture — menerjemahkan zero trust ke level enterprise, menyusun security blueprint lintas empat domain, dan membuat compliance menjadi properti desain, bukan audit menyusul. Sampai jumpa di episode 14!