Dalam dunia software engineering, ada sebuah prinsip sakral bin wajib: Jangan pernah melakukan optimasi prematur pada sistem yang belum stabil. Namun, terkadang kita melihat sebuah kebijakan besar yang terasa seperti memaksa deployment aplikasi berat ke atas infrastruktur yang sudah lama throttling.
Mari kita bedah program Makan Bergizi Gratis (MBG) menggunakan kacamata Platform Engineering. Jika pendidikan adalah sebuah sistem terdistribusi, di mana letak bottleneck sebenarnya?
1. Arsitektur Sistem: Memetakan Node dan Workload
Untuk memahami masalahnya, kita harus sepakat dulu dengan pemetaan komponennya:
- Sekolah = Server / Node: Tempat eksekusi terjadi.
- Siswa = Services / Workloads: Komponen yang seharusnya memberikan output (kecerdasan/keterampilan).
- Guru = Orchestrator (K8s, Docker, Scheduler): Yang mengatur alur kerja, alokasi sumber daya, dan memastikan service berjalan sesuai spek.
- Ekonomi Keluarga = Power Supply & Network Upstream: Input dasar agar node tetap menyala.
- MBG = Sidecar / External Tool: Add-on yang disuntikkan ke dalam sistem.
2. Isu Kapasitas: Deploy Tanpa Profiling
Dalam infrastructure management, tidak ada engineer waras yang berani melakukan mass-deployment sebuah tool berat ke seluruh cluster tanpa melakukan readiness check.
Realitas “Server” sekolah kita saat ini sedang mengalami masalah serius:
- CPU Throttling: Guru (Orchestrator) sudah overload dengan tugas administratif.
- RAM Minim: Kompetensi dasar yang memang perlu di- upgrade dari akarnya.
- Network Naik Turun: Kondisi ekonomi keluarga siswa yang tidak stabil membuat koneksi ke “server” sering terputus.
Nah, di tengah kondisi node yang kritis ini, kebijakan MBG datang seperti menyuntikkan sidecar container ke semua node secara paksa. Masalahnya adalah Tool ini tidak menambah core capacity, malah menambah beban manajemen pada orchestrator yang sudah mau tumbang.
3. Kenapa MBG Bukan Solusi Throughput?
Dalam optimasi performa, menambah input tidak otomatis menaikkan throughput jika bottleneck-nya bukan di sana.
MBG fokus pada menambah input (makanan), tetapi:
- Tidak memperbaiki Scheduler (Kurikulum).
- Tidak menyentuh Orchestration (Manajemen Guru).
- Tidak mengubah Admission Policy (Sistem seleksi dan standar kualitas).
Jika kalian adalah network engineer, maka secara teknis pasti bisa memprediksinya. Dimana Service akan tetap crash, latency (keterlambatan belajar) tetap tinggi, dan error rate (angka putus sekolah) tidak serta merta turun, dengan adanya sidecar MBG ini.
Menganggap makanan adalah satu-satunya solusi untuk meningkatkan kualitas service adalah sebuah anti-pattern klasik dalam dunia sistem.
4. Salah Layer: Mengobati Application dengan Patch Infrastructure
Masalah paling fatal dari kebijakan ini adalah salah penempatan layer. MBG bekerja di Application Layer (apa yang dikonsumsi siswa), padahal kerusakan sistem kita ada di level Infrastructure & Control Plane.
Yang rusak di sistem kita adalah:
- Control Plane: Guru tidak diberdayakan dan tidak memiliki akuntabilitas yang jelas karena beban sistem yang kacau.
- Resource Allocation: Waktu belajar habis untuk administrasi (kebocoran resource).
- Failure Handling: Tidak ada remediation otomatis untuk service (murid) yang mulai unhealthy atau tertinggal.
Menambah makanan ke sistem yang infrastrukturnya rusak sama saja dengan menaikkan request rate ke service yang sedang down. Bukannya makin kencang, yang ada malah cascading failure.
5. Cloud Billing: Overspending pada Sidecar, Underfunding pada Instance
Dalam manajemen cloud, setiap resource itu pasti ada harganya. Masalahnya, MBG ini bukanlah persoalan salah layer, tapi sebuah tools dengan alokasi budget tambahan.
Bayangkan Anda punya budget terbatas di AWS atau GCP. Alih-alih menggunakan budget tersebut untuk:
- Upgrade Instance: Menaikkan gaji dan kualitas Guru (Orchestrator).
- Reserved Instances: Investasi infrastruktur sekolah jangka panjang.
- Auto-scaling Group: Memperbaiki sistem agar siswa yang tertinggal otomatis dapat bantuan.
Bisa dikatakan, kebijakan MBG ini justru menghabiskan sebagian besar monthly burn rate untuk sebuah Third-party Managed Tool (Sidecar) yang tagihannya sangat membengkak.
Secara teknis, ini adalah Financial Anti-pattern:
“Kita membayar mahal untuk fitur tambahan (makanan), sementara server utama kita masih pakai spek t2.micro (sangat kecil) yang sering freeze saat mendapatkan beban kerja tinggi.” 😂
6. Legacy Debt vs. Shiny New Feature
MBG terasa seperti fitur baru yang “berkilau” (shiny new feature) yang dipaksakan rilis oleh tim Product Manager (pemerintah), padahal tim Engineering (pendidik & ahli sistem) tahu kalau sistem mereka punya banyak Legacy Debt (utang teknis) yang belum lunas.
Menambah beban biaya sebesar itu untuk sidecar tools tanpa melunasi utang teknis di level infrastruktur hanya akan mempercepat Budget Depletion.
Ujung-ujungnya, kita cuma melakukan Cash Burn untuk fitur tambahan, sementara Core Engine kita masih tertinggal jauh di bawah benchmark internasional. 💸💸💸
Kesimpulan
Secara teknis, MBG adalah sebuah observability tool mahal yang dipasang di cluster yang bahkan belum stabil untuk running aplikasi dasar. Sebelum kita sibuk menyuntikkan “suplemen” ke dalam container tersebut, bukankah lebih bijak jika kita memperbaiki power supply dan memperkuat resource pada node terlebih dahulu?
Tanpa perbaikan di level infrastruktur, maka sidecar semahal apa pun hanya akan menjadi beban tambahan bagi server yang sudah kepanasan.
Bagaimana pendapat saudara sekalian? Terima kasih.
Artikel ini adalah opini pribadi yang menggunakan analogi teknologi untuk membedah sebuah kebijakan secara logis, tanpa ada niat menyudutkan pihak manapun.
Tinggalkan Balasan