Dalam dunia software engineering, prinsip utama yang selalu harus dipegang teguh adalah: Jangan pernah melakukan optimalisasi prematur pada sistem yang tidak stabil. Namun, terkadang kebijakan besar terlihat seperti memaksa deployment aplikasi berat ke infrastruktur yang sudah lama throttling. Mari kita analisis program Makan Bergizi Gratis (MBG) dari sudut pandang Platform Engineering. Jika kita menganggap pendidikan sebagai sistem terdistribusi, di mana letak bottleneck sebenarnya?
Untuk memahami masalahnya, kita bisa memetakan komponen sebagai berikut: Sekolah sebagai Server/Node, Siswa sebagai Services/Workloads, Guru sebagai Orchestrator yang mengatur alur kerja, dan Ekonomi Keluarga sebagai Power Supply & Network Upstream yang merupakan input dasar agar node tetap berjalan. Lalu, MBG digambarkan sebagai Sidecar/External Tool yang ditambahkan ke dalam sistem.
Dalam manajemen infrastruktur, tidaklah bijaksana untuk melakukan mass-deployment sebuah tool berat ke seluruh cluster tanpa melakukan readiness check terlebih dahulu. Realitas saat ini adalah bahwa “Server” sekolah mengalami masalah serius, seperti CPU Throttling, RAM yang minim, dan gangguan koneksi Network. Di tengah kondisi kritis tersebut, kebijakan MBG terasa seperti memaksakan sidecar container ke semua node, yang justru menambah beban manajemen pada orchestrator yang sudah overload.
Dalam optimasi performa, menambah input tidak selalu meningkatkan throughput jika bottleneck-nya berada di tempat lain. MBG fokus pada menambah input tanpa memperbaiki Scheduler, Orchestration, atau Admission Policy. Dalam konteks ini, menambah makanan sebagai satu-satunya solusi untuk meningkatkan kualitas service merupakan suatu anti-pattern dalam dunia sistem.
Salah satu masalah fatal dari kebijakan ini adalah penerapan layer yang salah. MBG bekerja di Application Layer padahal kerusakan sistem terjadi di Infrastructure & Control Plane. Dimana Control Plane, Resource Allocation, dan Failure Handling mengalami masalah yang tidak terselesaikan. Mengalokasikan resource tambahan untuk sidecar tool tanpa memperbaiki infrastruktur dapat menyebabkan cascading failure.
Dalam manajemen cloud, setiap resource memiliki harganya. MBG menggunakan alokasi budget tambahan yang seharusnya bisa dialokasikan untuk upgrade instance, reserved instances, atau auto-scaling group. Kebijakan ini pada akhirnya hanya menghabiskan budget untuk Third-party Managed Tool yang sebenarnya tidak diperlukan.
MBG mungkin terlihat seperti fitur baru yang menarik, namun tanpa mengatasi legacy debt yang ada, kebijakan ini hanya akan mengakibatkan Budget Depletion. Sebelum menyuntikkan “suplemen” ke dalam container, perbaiki infrastruktur terlebih dahulu untuk memastikan keseluruhan sistem stabil. Karena tanpa perbaikan di level infrastruktur, sidecar tool mahal hanya akan menambah beban pada server yang sudah overload. Menarik untuk diskusikan lebih lanjut, terima kasih.
