Belajar Kubernetes Shared Filesystem RWX - Cost, Sizing & When to Move On

#Pendahuluan

Setelah 26 episode bangun, saatnya bertanya pertanyaan yang jarang dijawab jujur: apakah ini arsitektur yang tepat untuk kami, dan berapa biayanya? Episode 26 membawa kalian keluar dari mode "bagaimana caranya" ke mode "apakah sepadan".

Storage adalah keputusan bisnis: setiap teknologi punya biaya pembelian (CAPEX), biaya operasi (OPEX), dan biaya kesempatan. Kita hitung NFS sendiri, lalu bandingkan dengan alternatif — supaya keputusan migrasi bukan driven oleh gimmick, melainkan oleh angka.

#Biaya Total Saat Pakai NFS Sendiri

Hitung tiga komponen:

Hardware/infrastruktur — 1-2 server NFS (atau instance cloud), disk dengan RAID/redundansi, NIC khusus bila performa menuntut.
Operasional — waktu engineer untuk patch, monitor, backup, failover drill. Ini UANG — jam yang tidak bisa dipakai ngerjain fitur.
Hidden cost — SPOF downtime (episode 20), manajemen bila data berkembang (episode 16), dan migrasi ketika berubah pikiran.

Contoh kasar untuk 1 server NFS (disk 4 TB):

Item	Estimasi
Server/VM + disk RAID	$150-300/bln di cloud, atau CAPEX on-prem
Ops engineer (0.1 FTE)	$200-500/bln
Risiko downtime	Tidak terukur sampai terjadi

Sedangkan managed (EFS/Cloud Filestore): bayar per GB + I/O, tanpa biaya operasi. Untuk beban kecil, managed kerap lebih murah total; untuk beban besar yang konstan, self-host menang.

#Siapa yang Cocok Pakai NFS-based RWX

NFS-based RWX unggul pada profil ini:

Team kecil/medium (1-5 engineer infra).
Cluster bare-metal / lab yang sudah ada 5 node.
Workload web file-sharing: Laravel upload, gallery, CMS, shared config — data non-kritis dengan pola read-heavy.
Budget terbatas dan tidak ingin menyewa storage cloud per aplikasi.

Jika aplikasi kalian adalah "file ditulis sekali, dibaca banyak, hilang lebih baik", NFS sendiri adalah juara biaya.

#Kapan Migrasi ke Alternatif

Keputusan migrasi lahir dari kebutuhan yang tidak bisa dipenuhi, bukan tren:

Butuh replikasi & self-healing → Rook-Ceph: distributed (block+file+object), replikasi otomatis, self-healing. Mahal secara operasional, sepadan untuk produksi critical.
Lab murah, in-cluster, NFS cepat → OpenEBS NFS (dynamic NFS provisioner di atas Local PV): simple, tanpa mesin terpisah. Ideal untuk lab — pertimbangkan juga series Belajar Kubernetes Simple Shared Storage.
Kinerja tinggi RWO untuk DB → Longhorn: replicated block storage dengan UI dan fitur backup sederhana.

Note

Migrasi bukan "semua atau tidak". Banyak arsitektur bergerak ke storage hibrida: media di NFS sederhana, database di Longhorn/RBD, arsip besar di object. Pisahkan berdasarkan karakter beban, bukan satu pilihan untuk semua.

#Ringkasan Keputusan Storage

Bagan keputusan sederhana:

Kebutuhan	Pilihan
RWX files sederhana	NFS (self-host) / CephFS / OpenEBS-NFS
RWO DB performa tinggi	Longhorn / local-path / RBD(Ceph)
RWX + replikasi + petabyte	CephFS / distributed
Object/archival besar	S3 / MinIO
Multi-site DR	Distributed / managed cloud

Tentukan karakter beban utama (files vs block vs object; critical vs bukan; skala), lalu cocokkan ke kolom.

#Penutup

Pada episode 26 ini, kalian kini memandang storage sebagai investasi:

Inti yang harus dibawa pulang:

Biaya NFS = hardware + ops + hidden (downtime, manajemen pertumbuhan).
Cocok untuk team kecil/medium, cluster bare-metal, workload web files.
Migrasi ketika kebutuhan berubah: CephFS/Rook (replikasi+self-healing), OpenEBS NFS (lab), Longhorn (RWO DB).
Storage hibrida lebih umum daripada tunggal.
Keputusan storage didasarkan pada karakter beban, bukan tren.

Di episode 27 (terakhir) selanjutnya kita akan merefleksikan seluruh perjalanan: rekap arsitektur final, simulasi skala dan failover pendek, sesi problem-solving, dan peta belajar lanjutan. Sampai jumpa di episode 27!