Setiap beberapa bulan, ada saja pemilik bisnis yang bertanya apakah mereka harus "pindah ke microservices" karena kompetitor menyebutkannya, atau karena seorang konsultan menawarkannya sebagai cara modern membangun software. Perdebatan monolith vs microservices memang punya substansi nyata, tapi hampir semua substansi itu bukan soal mana yang secara teknis lebih unggul. Ini soal skala organisasi, dan kebanyakan UKM sedang mengoptimalkan untuk masalah yang belum mereka miliki.
Saya sudah membangun dan memelihara keduanya, di tim mulai dari tiga engineer sampai dua puluh, dan saya ingin memberi Anda versi bahasa sederhana dari keputusan ini, versi yang melewati jargon konferensi arsitektur dan langsung ke hal yang benar-benar penting untuk bisnis Anda.
Apa Sebenarnya Masing-Masing Ini
Monolith adalah satu aplikasi, satu codebase, satu deployment. Logika inventaris, akun pelanggan, pemrosesan pembayaran, pelaporan, semuanya hidup dalam satu sistem yang sama dan di-deploy bersamaan. Saat Anda memperbaiki bug atau menambah fitur, Anda mengirim seluruh aplikasi, meski Anda hanya mengubah satu bagian kecil.
Microservices memecah fungsionalitas yang sama itu menjadi layanan-layanan terpisah yang dapat di-deploy secara independen. Inventaris menjadi layanannya sendiri, pembayaran menjadi layanannya sendiri, masing-masing dengan codebase sendiri, database sendiri dalam versi ketat dari pola ini, dan pipeline deployment sendiri. Mereka berkomunikasi satu sama lain lewat jaringan, bukan memanggil langsung di dalam kode.
Tidak ada yang "lebih maju." Microservices adalah respons terhadap satu rasa sakit spesifik: tim engineering besar yang saling menginjak pekerjaan satu sama lain di dalam satu codebase bersama. Kalau Anda belum punya rasa sakit itu, mengadopsi pola ini lebih awal berarti membayar biayanya tanpa memetik manfaatnya.
Pemicu Sebenarnya Adalah Ukuran Tim, Bukan Ambisi
Ini pemicu skala yang jujur, dari pengalaman, bukan dari buku teks: microservices mulai membayar dirinya sendiri ketika Anda punya cukup banyak engineer sehingga satu codebase bersama menjadi bottleneck koordinasi, biasanya di atas 15 sampai 20 engineer yang bekerja di produk yang sama, terorganisir dalam beberapa tim independen yang kalau tidak akan saling memblokir deploy satu sama lain setiap hari.
Di bawah ukuran itu, memecah sistem Anda menjadi layanan-layanan sebagian besar hanya menambah overhead: lebih banyak infrastruktur untuk dikelola, lebih banyak panggilan jaringan yang bisa gagal, lebih banyak tempat bug bisa bersembunyi lintas batas layanan, dan standar perekrutan yang jauh lebih tinggi, karena sekarang Anda butuh engineer yang nyaman dengan debugging sistem terdistribusi, bukan sekadar kode aplikasi.
Saya pernah melihat tim engineering berisi lima orang mengadopsi microservices karena terlihat lebih "enterprise," lalu menghabiskan porsi minggu kerja yang tidak proporsional untuk debugging kenapa Service A tidak bisa mencapai Service B, waktu yang seharusnya dipakai untuk mengirim fitur. Arsitektur itu sedang menyelesaikan masalah koordinasi tim yang tidak mereka miliki, dengan biaya masalah keandalan yang mereka ciptakan sendiri.
Kapan Monolith yang Bersih Justru Lebih Murah
Untuk mayoritas besar UKM Indonesia dan perusahaan menengah yang saya tangani, monolith yang dibangun dengan baik adalah pilihan yang tepat, dan ini bukan kompromi, ini struktur biaya yang secara objektif lebih baik pada skala tersebut.
Alasan monolith menang untuk tim yang lebih kecil:
- Lebih murah dibangun. Satu codebase, satu pipeline deployment, satu set infrastruktur untuk disiapkan dan dipantau. Anda tidak membayar untuk container orchestration, service discovery, dan distributed tracing sebelum benar-benar membutuhkannya.
- Lebih murah dijalankan. Lebih sedikit moving parts berarti lebih sedikit server, lebih sedikit dashboard monitoring, lebih sedikit tempat gangguan jam 2 pagi bisa berasal. Klien perusahaan finance saya memangkas biaya infrastruktur sekitar 40 persen setelah mengonsolidasikan setup microservices yang terlalu bersemangat kembali menjadi tiga modul yang terorganisir baik di dalam satu monolith.
- Lebih murah untuk merekrut. Mencari engineer yang bisa produktif di monolith yang terstruktur baik sejak hari pertama jauh lebih mudah dan murah dibanding mencari engineer berpengalaman di sistem terdistribusi, message queue, dan tooling service mesh. Khusus di pasar Indonesia, talent pool untuk itu lebih tipis dan lebih mahal.
- Lebih cepat dipahami. Saat sesuatu rusak, seorang engineer bisa menelusuri bug lewat satu codebase, bukan melompat lintas batas layanan dan log aggregator sambil mencoba merekonstruksi apa yang terjadi di lima sistem berbeda.
Ini bukan berarti menulis kode secara sembarangan. Monolith yang dibangun dengan batas modul internal yang jelas, di mana logika inventaris, logika pembayaran, dan logika pelaporan terpisah rapi di dalam kode meski di-deploy bersamaan, memberi Anda hampir semua kejelasan organisasi dari microservices tanpa biaya operasionalnya. Ini sering disebut "modular monolith," dan ini adalah titik ideal untuk sebagian besar perusahaan tahap pertumbuhan. Kalau rasa sakit sistem Anda saat ini terasa lebih seperti kode yang kusut daripada koordinasi tim, solusinya biasanya merapikan menjadi modular, bukan memecah menjadi layanan-layanan.
Pemicu yang Jujur untuk Memecah Sistem
Pecah menjadi microservices ketika Anda bisa menunjuk pada rasa sakit yang spesifik dan sedang terjadi, bukan yang hipotetis di masa depan:
| Pemicu | Seperti apa dalam praktiknya |
|---|---|
| Bottleneck koordinasi tim | Beberapa tim independen rutin terblokir oleh deploy satu sama lain dalam codebase yang sama |
| Kebutuhan skala yang benar-benar independen | Satu komponen (misalnya layanan notifikasi) perlu skala hingga 100x traffic sementara sistem lainnya tidak |
| Kebutuhan teknologi yang berbeda | Satu komponen spesifik benar-benar butuh bahasa atau runtime berbeda yang tidak bisa disediakan stack Anda saat ini |
| Isolasi regulasi atau keamanan | Satu komponen harus diisolasi untuk alasan kepatuhan, tidak tergantung ukuran tim |
Perhatikan bahwa "ini cara modern membangun software" dan "kompetitor kami melakukannya" tidak ada dalam daftar itu. Itu adalah tren, bukan pemicu, dan mengikuti tren masuk ke sistem terdistribusi yang belum Anda butuhkan adalah salah satu kesalahan paling mahal yang saya lihat dilakukan perusahaan yang sedang tumbuh.
Intinya
Untuk hampir semua UKM dan perusahaan tahap pertumbuhan, monolith yang bersih dan termodularisasi dengan baik lebih murah untuk dibangun, dijalankan, dan direkrut dibanding arsitektur microservices, dan itu akan melayani Anda jauh melampaui titik yang diperkirakan kebanyakan pemilik bisnis. Pecah menjadi layanan-layanan hanya ketika Anda bisa menunjuk pada rasa sakit koordinasi tim atau kebutuhan skala independen yang spesifik dan sedang Anda alami hari ini, bukan skala yang mungkin Anda capai suatu saat. Kalau Anda belum yakin di sisi mana bisnis Anda berada, itu percakapan yang layak dibahas bersama partner sebelum mengorbankan bulan-bulan waktu engineering untuk rebuild yang mungkin tidak Anda butuhkan.