Monolith vs Microservices: Arsitektur Mana yang Cocok untuk Tim Anda?

Ada satu jenis diagram arsitektur yang lebih sering muncul dari seharusnya. Empat belas service, satu message broker, cluster Kubernetes, dan tim developernya empat orang. Produknya sendiri belum rilis. Enam bulan kemudian, waktu tim lebih banyak habis untuk debugging komunikasi antar service daripada membuat fitur. Microservices adalah jawaban yang bagus untuk masalah tertentu, dan kebanyakan itu masalah organisasi besar. Kalau masalah itu belum Anda alami, Anda menanggung biayanya tanpa menikmati manfaatnya.

Apa Artinya dalam Praktik

Monolith adalah satu aplikasi yang di-deploy sebagai satu kesatuan, biasanya dengan satu database. Aplikasi Laravel atau Django yang punya modul pesanan, stok, dan tagihan itu monolith. Microservices memecah modul-modul tadi menjadi aplikasi terpisah. Masing-masing punya codebase sendiri, deployment sendiri, idealnya database sendiri, dan saling berkomunikasi lewat jaringan, entah HTTP, gRPC, atau message queue.

Daya tariknya gampang dipahami. Tim bisa deploy sendiri-sendiri, bagian yang berat bisa di-scale terpisah, dan kalau satu service error, sistem lainnya tidak harus ikut mati. Semua itu benar. Pertanyaannya, berapa harga yang harus dibayar.

Biaya yang Tidak Kelihatan di Diagram

• Gangguan jaringan. Pemanggilan fungsi di dalam monolith tidak pernah timeout. Pemanggilan ke service lain bisa. Jadi setiap panggilan butuh timeout, retry, dan penanganan idempotent supaya pembayaran yang di-retry tidak tertagih dua kali.
• Konsistensi data. Dulu pesanan dan pengurangan stok cukup satu transaksi database. Kalau sudah beda service, perlu pola seperti outbox atau saga, dan Anda harus terima bahwa data sempat tidak sinkron sebentar.
• Observability. Kalau satu request melewati lima service, log saja tidak cukup. Perlu distributed tracing dengan tool seperti OpenTelemetry, logging terpusat, dan metrik per service.
• Operasional. Setiap service perlu pipeline CI/CD, konfigurasi, secrets, health check, dan penanggung jawab on-call sendiri. Ujung-ujungnya biasanya Kubernetes, plus orang yang benar-benar paham Kubernetes.
• Development di lokal. Menjalankan seluruh sistem di laptop jadi susah. Untuk mengetes satu perubahan dari ujung ke ujung, tim sering harus antre memakai staging bersama.

Untuk tim kecil, beban tambahan ini bisa memakan sepertiga waktu engineering. Perusahaan besar pun meninjau ulang pilihannya. Tahun 2023 tim Amazon Prime Video menulis tentang satu sistem monitoring mereka yang dipindah dari komponen terdistribusi kembali ke satu proses, dan biaya infrastrukturnya turun sekitar 90 persen.

Modular Monolith sebagai Titik Awal

Untuk kebanyakan perusahaan yang kami tangani, titik awal yang paling masuk akal adalah modular monolith. Aplikasinya tetap satu dan di-deploy sekali, tapi kodenya dibagi ke modul dengan batas yang jelas. Pesanan, pembayaran, dan stok masing-masing punya folder atau package sendiri, hanya membuka interface kecil ke luar, dan tidak mengakses tabel milik modul lain. Shopify terkenal menjalankan salah satu codebase Rails terbesar di dunia dengan cara ini.

Anda dapat sebagian besar manfaat desain dari microservices, yaitu batas yang rapi dan kode yang jelas pemiliknya, tanpa jaringan di tengahnya. Kalau suatu saat satu modul memang perlu jadi service, batasnya sudah ada. Memisahkan modul yang sudah rapi butuh beberapa minggu. Mengurai monolith yang kusut bisa berbulan-bulan.

Tanda Anda Memang Perlu Memecah Sistem

• Ukuran tim. Begitu ada beberapa tim, kira-kira 30 sampai 50 engineer ke atas, dan mereka terus saling menghambat di rilis yang sama, deployment terpisah mulai terasa manfaatnya.
• Kebutuhan scaling yang jauh berbeda. Pemrosesan gambar, indexing pencarian, atau pengirim notifikasi yang butuh resource sepuluh kali lipat dari bagian lain adalah kandidat yang bagus.
• Ritme rilis yang berbeda. Mesin harga yang berubah tiap hari bersebelahan dengan modul tagihan yang berubah per kuartal dan butuh review ketat.
• Kebutuhan isolasi. Komponen yang mengolah data kartu atau data lain yang diatur regulasi. Dengan dipisah, cakupan audit jadi lebih kecil.
• Teknologi lain lebih cocok. Misalnya service Go untuk gateway bertrafik tinggi di samping aplikasi bisnis berbasis PHP.

Perhatikan apa yang tidak ada di daftar itu. Ingin pakai teknologi kekinian, berharap suatu hari jadi besar, atau monolith yang berantakan, semuanya alasan yang lemah. Monolith berantakan yang dipecah jadi service hasilnya sistem terdistribusi yang berantakan, dan itu lebih parah.

Cara Memisahkan Service dengan Aman

Pendekatan yang terbukti jalan adalah strangler fig pattern, istilah yang dipopulerkan Martin Fowler. Sistemnya tidak ditulis ulang. Anda mengalihkan satu fungsi demi satu fungsi ke service baru sementara kode lama tetap berjalan, lalu kode lama dibuang setelah jalur barunya terbukti stabil.

1. 1Pilih satu modul dengan batas yang jelas dan alasan nyata untuk dipindah, misalnya notifikasi atau laporan. Jangan mulai dari alur pesanan inti.
2. 2Rapikan batasnya di dalam monolith dulu. Semua akses lewat satu interface, dan tidak ada modul lain yang membaca tabelnya langsung.
3. 3Bangun service baru di balik interface yang sama, dengan tracing, monitoring, dan alert sejak hari pertama.
4. 4Arahkan sebagian kecil trafik ke service baru, bandingkan hasilnya dengan jalur lama, lalu naikkan bertahap.
5. 5Pindahkan datanya supaya dimiliki service itu, lalu hapus kode dan tabel lama setelah tidak ada lagi yang bergantung padanya.

Kepemilikan Data adalah Batas yang Sebenarnya

Setiap service harus memiliki datanya sendiri. Service lain bertanya lewat API atau mendengarkan event, tidak langsung query ke database-nya. Beberapa service yang berbagi satu database dan sama-sama menulis ke sana itu kombinasi terburuk: overhead jaringan ala microservices plus ketergantungan erat ala monolith. Kalau dua service selalu harus mengubah tabel yang sama secara bersamaan, kemungkinan besar keduanya memang satu service.

Arsitektur Mengikuti Struktur Tim

Hukum Conway menyebutkan bahwa sistem pada akhirnya akan mencerminkan struktur komunikasi organisasi yang membangunnya. Ini berlaku dua arah. Sepuluh service yang dipegang satu tim berisi lima orang berarti setiap developer harus memahami seluruh sistem terdistribusi itu di kepalanya. Satu monolith raksasa yang dikerjakan delapan tim berarti konflik merge dan koordinasi rilis tanpa henti. Tentukan pembagian tim dulu, baru batas service mengikuti.

Mulai dengan monolith yang bisa dipecah, lalu pecah saat tim yang memintanya, bukan diagram.

Di Salamun Teknologi kami merancang dan membangun backend untuk perusahaan yang sedang tumbuh, dari modular monolith dengan Laravel atau Go sampai service di Kubernetes kalau beban dan ukuran timnya memang menuntut. Kalau Anda sedang menimbang untuk memecah sistem atau menulis ulang, kita bisa review sistem yang sekarang bersama sebelum ada kode yang diubah.