Suatu kali sebuah vendor mengusulkan arsitektur microservices, delapan layanan, tiga message queue, pipeline deployment terpisah untuk masing-masing, untuk aplikasi inventaris internal yang melayani 40 staf gudang. Perusahaan itu hanya punya satu backend developer. Monolith vs microservices untuk bisnis kecil seharusnya bahkan tidak jadi perdebatan pada skala segitu, tapi saya terus-menerus melihat pitch semacam ini, biasanya dari tim yang lebih ingin baris CV yang menarik ketimbang benar-benar menyelesaikan masalah Anda.
Ini kebenaran yang tidak enak didengar: microservices menyelesaikan masalah organisasi, bukan masalah teknis. Mereka ada supaya tim engineering besar bisa mengerjakan bagian sistem yang berbeda tanpa saling menginjak, dan supaya komponen yang berbeda bisa di-scale secara independen di bawah beban yang benar-benar berbeda. Kalau Anda punya satu tim, atau bahkan tiga tim, dan traffic yang tidak melonjak sepuluh kali lipat berbeda antar fitur, Anda tidak punya masalah itu. Yang Anda punya adalah bisnis yang butuh software yang bekerja andal, rilis cepat, dan tidak memerlukan tim platform untuk memeliharanya.
Ini adalah izin untuk menolak lain kali ada yang menawarkan kuotasi arsitektur terdistribusi untuk sistem yang sebetulnya muat nyaman dalam satu codebase yang terorganisir dengan baik.
Microservices menyelesaikan masalah organisasi, bukan masalah teknis.
Ervandra Halim
Apa yang Membenarkan Pemecahan Sistem Menjadi Microservices?
Pemecahan sistem menjadi microservices baru dibenarkan dalam kondisi tertentu yang bisa dicek: ukuran tim, profil skalabilitas yang benar-benar berbeda, kadensi rilis independen, atau kebutuhan polyglot yang nyata. Kalau tak satu pun dari kondisi ini berlaku untuk bisnis Anda, berhenti membaca proposal vendor yang mengasumsikan sebaliknya, karena pajak kompleksitas itu tidak memberi apa-apa pada skala Anda.
- Ukuran tim melewati kira-kira 15-20 engineer yang bekerja pada produk yang sama, di mana codebase bersama menciptakan merge conflict terus-menerus dan overhead koordinasi deployment.
- Profil skalabilitas yang benar-benar berbeda. Layanan checkout Anda menerima traffic 50x lipat dari panel pelaporan admin, dan Anda perlu men-scale keduanya secara independen ketimbang membayar untuk over-provisioning seluruh aplikasi.
- Kadensi rilis independen adalah kebutuhan bisnis yang nyata. Satu tim perlu deploy harian, tim lain menyentuh kode sebulan sekali, dan menyatukan rilis mereka justru memperlambat bisnis.
- Kebutuhan polyglot. Anda benar-benar memerlukan bahasa atau runtime berbeda untuk satu komponen (misalnya layanan machine learning berbasis Python yang ditempel pada aplikasi Node.js).
Perhatikan apa yang tidak masuk daftar: "lebih scalable" dan "cara modern membangun software" bukan justifikasi engineering, itu bahasa marketing.
Apa Biaya Nyata yang Tidak Pernah Diberitahukan ke Anda?
Biaya nyata yang tidak pernah diberitahukan ke Anda adalah luas permukaan operasional, dan itu melipatgandakan diri setiap kali Anda menambah satu microservice. Setiap layanan baru butuh service discovery, penanganan keandalan jaringan (timeout, retry, circuit breaker), distributed tracing untuk melacak satu request yang menyentuh empat layanan, pipeline CI/CD terpisah, dan kompatibilitas versi antar layanan yang berkembang secara independen.
Untuk tim dua atau tiga developer, overhead ini bukan biaya satu kali, ini pajak permanen pada setiap fitur yang Anda kirim. Bug yang di monolith cukup dua puluh menit untuk dilacak (baca stack trace, temukan fungsinya) bisa memakan setengah hari di sistem terdistribusi (layanan mana yang mencatat error, apakah itu timeout atau kegagalan sungguhan, versi mana yang sedang deploy saat itu terjadi).
Saya pernah menyaksikan sebuah tool finance internal untuk 500 pengguna dibangun ulang sebagai microservices, dan timnya berubah dari merilis fitur tiap minggu menjadi tiap bulan, bukan karena bisnisnya jadi lebih kompleks, tapi karena setiap perubahan sekarang menyentuh tiga repository dan dua pipeline deployment, bukan satu.
Seperti Apa Sebenarnya Monolith yang Dibangun dengan Baik?
Monolith yang dibangun baik terlihat rapi secara internal, bukan berantakan, dan kerapian internal itulah yang sebenarnya membedakannya dari monolith yang sering dikeluhkan orang. Keluhan terhadap monolith biasanya sebetulnya keluhan terhadap monolith yang berantakan, bukan terhadap pola monolith itu sendiri. Monolith yang dibangun baik memiliki:
- Batas modul internal yang jelas. Logika billing, logika inventaris, dan manajemen pengguna Anda hidup di folder atau modul terpisah dengan interface yang terdefinisi di antaranya, meski mereka di-deploy bersama.
- Satu test suite yang cepat yang berjalan dalam hitungan menit, bukan jam, sehingga developer mendapat feedback cepat.
- Satu pipeline deployment yang merilis seluruh aplikasi secara andal, jauh lebih sederhana untuk dipikirkan ketimbang mengoordinasikan banyak layanan.
- Skema database yang mencerminkan batas bisnis nyata, meski cuma satu database, tabel dan pola akses tetap bisa dipisahkan dengan rapi menurut domain.
Struktur ini, kadang disebut "modular monolith," memberi Anda hampir semua kejelasan organisasi dari microservices tanpa kompleksitas jaringannya. Dan yang krusial, kalau suatu saat Anda benar-benar melewati ambang ukuran tim atau skalabilitas yang membenarkan pemecahan, monolith yang termodularisasi dengan baik bisa dipecah dengan bersih. Yang berantakan tidak bisa, terlepas dari apakah ia mulai sebagai monolith atau microservices.
Cara Mengetahui Vendor Anda Sedang Menjual Kompleksitas
Ajukan tiga pertanyaan ini saat seseorang mengusulkan arsitektur terdistribusi untuk bisnis Anda:
- "Berapa banyak engineer yang akan mengerjakan ini di tahun pertama?" Kalau jawabannya di bawah lima, minta mereka membenarkan pemecahan itu secara konkret.
- "Masalah skalabilitas spesifik apa yang diselesaikan ini yang tidak bisa diselesaikan satu database dan app server yang terindeks baik?" Jawaban samar soal "skala masa depan" adalah tanda bahaya.
- "Berapa biaya operasional tambahan, dalam jam per bulan, untuk menjalankan ini dibanding monolith?" Kalau mereka tidak bisa menjawab, mereka belum memikirkan siapa yang akan merawat ini setelah rilis.
Insting yang sama, mengecek apakah sebuah proposal cocok dengan skala Anda yang sebenarnya, bukan dengan ambisi vendor Anda, berlaku secara luas. Kalau Anda sedang mengevaluasi apakah redesain website itu layak atau cuma gengsi, disiplin yang sama berlaku: cocokkan pengeluaran dengan kebutuhan bisnis yang bisa dicek, bukan dengan apa yang terdengar mengesankan di pitch deck.
Kapan Anda Sebaiknya Benar-Benar Mempertimbangkan Pemecahan
Kalau tim Anda benar-benar sudah tumbuh melewati 15-20 engineer pada satu produk, atau satu komponen spesifik punya profil skalabilitas sepuluh kali berbeda dari sisa sistem Anda, mulailah dengan memecah komponen itu saja, bukan merombak semuanya sekaligus. Ekstrak bagian yang benar-benar tertekan (sering kali layanan pencarian, layanan notifikasi, atau job pelaporan berat) dan biarkan sisanya tetap sebagai monolith. Pendekatan bertahap ini adalah cara kebanyakan adopsi microservices yang berhasil sebenarnya terjadi, bukan sebagai rewrite big-bang, tapi sebagai ekstraksi yang teruji tekanan seiring waktu.
Kesimpulan Praktisnya
Monolith vs microservices untuk bisnis kecil bermuara pada satu pertanyaan: apakah ukuran tim atau kebutuhan skalabilitas Anda benar-benar membenarkan pajak operasional sistem terdistribusi? Untuk mayoritas besar UKM yang saya tangani, jawaban jujurnya adalah tidak, belum saatnya, dan mungkin tidak akan pernah. Bangun satu aplikasi yang terorganisir dengan baik, jaga batas modul Anda tetap bersih, dan tolak proposal apa pun yang menambah kompleksitas terdistribusi tanpa alasan spesifik yang bisa dicek. Kalau vendor tidak bisa menyebutkan alasan itu dalam satu kalimat, mereka sedang menjual portofolio mereka, bukan menyelesaikan masalah Anda.
