Belajar Kubernetes Simple Shared Storage - Cost & Trade-Off Simplicity

#Pendahuluan

Keputusan "memakai OpenEBS atau membeli managed storage" bukan hanya soal fitur — ini hitungan ekonomi dan operasional. Episode 24 membuka kalkulator: berapa biaya menyimpan di cloud versus mengoperasikan storage sendiri di private/bare-metal, dengan trade-off simplicity yang jujur.

Angka di sini ilustratif untuk pendekatan berpikir — nilai riil tergantung harga penyedia dan kebutuhan kalian.

#Managed Cloud Pricing

#EBS (block, RWO) — AWS/GCP

Harga EBS tergantung tipe dan throughput:

text

gp3:     $0.08 / GB / bulan (+ IOPS/throughput tambahan)
io2:     $0.125 / GB / bulan (IOPS lebih tinggi)

Untuk database 20Gi → ~$1,6-2,5/bulan per volume; mudah dihitung dan diprediksi.

#EFS (file, RWX) — AWS

Harga per GB + throughput termurah hanya untuk file and RWX:

text

EFS Standard:      $0.08 / GB / bulan (plus throughput di bawah 1x)
EFS Infrequent:    $0.016 / GB / bulan

Flexibilitas RWX dimulai dengan harga $/GB setara block, namun minimal throughput dan I/O per request membuat label "tidak mahal di awal" sering mengecoh — hitung total bulanan dengan throughput yang dibutuhkan.

#Total Cost of Ownership (OpenEBS)

Untuk OpenEBS di bare-metal/private cloud, biaya tersebar di komponen:

Komponen	Perkiraan
Hardware (disk + node)	sekali, modal
Network (pod-network, switch)	tetap
Operasional (personel, runbook, monitoring)	per bulan
License	open-source (0)
Risiko (lewat runbook, backup)	tak terukur namun nyata
Power/cooling (DC)	per bulan

Pada 3 worker + 5 storage node, perkiraan kasar: modal ±3x harga 3 disk besar + opers personel parsial — sering lebih murah per GB di skala besar, namun biaya tetap (personel, hardware standby) hadir bahkan di volume kecil.

Note

Persamaan penting: OpenEBS murah per GB, mahal per kompleksitas. Managed cloud mahal per GB, murah per "ujung belakang" (backup, HA, upgrade) yang ditangani penyedia. Kedua sisi menang di dunia berbeda.

#Simplicity Trade-off

Prinsip sederhana untuk memilih:

Kebutuhan aplikasi: RWX multi-replica (web media) → fitur yang hanya di sini bernilai.
Skala tim: 1-3 personel → operasional mandiri itu mahal waktu; jika 10+ dengan SRE → internal murah per head.
Akselerasi fitur: kebut rilis → managed (tidak perlu runbook storage); kecepatan tinggi.
Data privacy / biaya transfer: data sensitif, DC sendiri → internal lebih masuk akal (control lokasi & latency).

Ketika 4 jawaban sudah jelas, pilihan tak lagi ambigu.

#Kapan "Move On"

Berhenti memakai OpenEBS (atau beralih ke managed) adalah keputusan sehat, dalam kondisi:

Jumlah volume kecil — 1-5 PVC total; offered managed lebih murah dari ops personel.
Vendor control dibutuhkan serius — SLA cloud & recovery mekanis di atas budget internal.
Tim tidak menambah skill — tidak ada yang merawat runbook; risiko teknik tak tercover.
Upgrade/kompatibilitas menjadi penghalang rilis — biaya waktu bisa melebihi harga managed.

Sebaliknya, bertahan masuk akal saat: skala besar, kebutuhan RWX/exotic engine (ZFS dedup), atau keterbatasan lokasi (air-gapped/edge) yang menggagalkan cloud.

Tip

Ambil keputusan berdasar corak 24 bulan: proyeksikan jumlah volume, personel, dan biaya. Corak titik (harga cloud naik) vs garis (biaya internal) — di mana keduanya menyilang? Itulah ambang "move on".

#Penutup

Pada episode 24 ini, keputusan storage berpijak pada angka:

Inti yang harus dibawa pulang:

Cloud (EBS/EFS): prediktabel per GB + throughput, minimal opers.
OpenEBS: murah per GB di skala besar, tetap ada biaya personel/hardware.
Empat prinsip: kebutuhan aplikasi, skala tim, kecepatan rilis, data privacy.
Move on jika: volume kecil, butuh SLA berat, tim tak bertumbuh, upgrade menghambat.
Hitung corak 24 bulan sebelum final — data mengalahkan perasaan.

Di episode 25 selanjutnya kita akan berlatih troubleshooting: masalah umum PVC pending, NFS server down/hang, performa menurun, mount NFS gagal — lengkap dengan urutan diagnosis dan solusi yang dapat dipraktikkan langsung. Sampai jumpa di episode 25!