Monolith vs Microservice: Panduan Lengkap Memilih Arsitektur yang Tepat

Apa Sebenarnya Arsitektur Monolitik Itu

Arsitektur monolitik adalah sistem software yang dibangun dan diterapkan sebagai satu kesatuan yang utuh. Seluruh fungsionalitas aplikasi—mulai dari autentikasi pengguna, logika bisnis, akses data, hingga lapisan presentasi—berada dalam satu basis kode, dikompilasi atau dikemas bersama, dan dijalankan sebagai satu proses tunggal (atau sekumpulan replika identik dari proses tersebut dalam penerapan berskala horizontal). Ketika developer melakukan perubahan pada bagian mana pun dari sistem, seluruh aplikasi harus dibangun ulang, diuji, dan diterapkan kembali secara keseluruhan, meskipun perubahan tersebut hanya memengaruhi satu fitur kecil.

Penting untuk memahami secara tepat apa arti dan bukan arti dari istilah "monolith", karena istilah ini sering digunakan secara tidak akurat dan terkadang dengan nada meremehkan. Monolith tidak selalu berarti kode yang tidak teratur atau semrawut; monolith yang dibangun dengan baik dapat memiliki batasan internal yang rapi, modul-modul yang terpisah dengan jelas, serta antarmuka yang tertata apik antar-komponennya, sembari tetap dikompilasi dan diterapkan sebagai satu kesatuan. Ciri utama monolith bukanlah kualitas kode internalnya, melainkan batasan deployment dan prosesnya, yaitu semuanya didistribusikan bersama, dijalankan bersama, dan (dalam implementasi yang sederhana) mengalami kegagalan secara bersamaan.

Secara internal, monolith yang terstruktur dengan baik biasanya diatur ke dalam lapisan atau modul yang memisahkan tanggung jawab, meskipun secara fisik atau operasional tidak terpisah. Pola yang umum digunakan adalah arsitektur berlapis, yang terdiri dari lapisan presentasi untuk menangani permintaan dan respons HTTP, lapisan logika bisnis untuk menerapkan aturan dan proses aplikasi yang sesungguhnya, serta lapisan akses data yang bertanggung jawab membaca dan menulis ke database. Monolith yang lebih canggih diatur berdasarkan domain bisnis alih-alih lapisan teknis—misalnya modul manajemen pengguna, modul pemrosesan pesanan, dan modul inventaris—dengan antarmuka yang jelas antar-modul tersebut, meskipun semuanya dikompilasi menjadi satu artefak yang dapat diterapkan dan berbagi proses runtime yang sama.

Selama sebagian besar sejarah pengembangan aplikasi web, monolith merupakan satu-satunya cara perangkat lunak dibangun—bukan sebagai pilihan arsitektur yang disengaja untuk menandingi alternatif lain, melainkan karena perangkat pendukung, praktik deployment, dan infrastruktur yang membuat microservices menjadi praktis belum dikembangkan atau diadopsi secara luas pada saat itu. Aplikasi Ruby on Rails, aplikasi Django versi awal, serta sebagian besar aplikasi Java skala perusahaan yang dibangun sepanjang tahun 2000-an hingga sebagian besar tahun 2010-an merupakan sistem monolitik; bahkan hingga saat ini, banyak sistem berskala besar yang sangat sukses masih beroperasi sebagai monolith, termasuk sistem yang menangani lalu lintas produksi dalam volume besar di perusahaan-perusahaan teknologi terkemuka.

Apa Sebenarnya Arsitektur Microservices Itu

Arsitektur microservices memecah sebuah aplikasi menjadi kumpulan layanan kecil yang dapat dideploy secara independen. Setiap layanan bertanggung jawab atas fungsi bisnis tertentu yang cakupannya relatif terbatas dan berkomunikasi satu sama lain melalui jaringan—biasanya menggunakan API HTTP/REST, gRPC, atau sistem pesan asinkron—alih-alih melalui pemanggilan fungsi langsung di dalam proses yang sama.

Ciri khas microservices, yang membedakannya dari arsitektur monolitik, adalah bahwa setiap layanan memiliki siklus hidup deployment-nya sendiri. Sebuah tim dapat memodifikasi, menguji, dan men-deploy Order Service tanpa perlu menyentuh, menguji ulang, atau men-deploy ulang Inventory Service, Payment Service, atau User Service, meskipun semua layanan ini secara kolektif membentuk aplikasi utuh yang dirasakan pengguna sebagai satu produk yang koheren. Setiap layanan biasanya dikelola oleh tim khusus, memiliki basis kode sendiri (atau setidaknya direktori dengan batasan yang jelas di dalam repositori yang lebih besar), dan sering kali memiliki penyimpanan data khusus alih-alih berbagi satu database dengan layanan lainnya.

Landasan konseptual untuk memecah sistem menjadi microservices secara terarah—bukan secara sembarangan—banyak mengacu pada domain-driven design, khususnya konsep bounded context, yaitu batasan di mana model domain bisnis tertentu berlaku secara konsisten dan tanpa ambiguitas. Arsitektur microservices yang dirancang dengan baik akan mengidentifikasi batasan-batasan alami dalam bisnis tersebut (seperti Manajemen Pesanan, Inventaris, Pembayaran, Identitas Pelanggan, Pengiriman, dan Notifikasi) dan membangun layanan untuk masing-masing batasan tersebut. Model data internal dan logika bisnis layanan itu pun mencerminkan aspek-aspek spesifik dari domain tersebut tanpa perlu mengakomodasi kebutuhan domain lain dalam sistem.

Microservices berkomunikasi satu sama lain melalui salah satu dari dua pola utama. Komunikasi sinkron, yang biasanya menggunakan HTTP/REST atau gRPC, melibatkan satu layanan yang memanggil layanan lain secara langsung dan menunggu respons sebelum melanjutkan proses—metode ini tepat digunakan ketika layanan pemanggil benar-benar membutuhkan hasil dari panggilan tersebut untuk dapat melanjutkan tugasnya. Komunikasi asinkron, yang biasanya dilakukan melalui antrean pesan atau aliran peristiwa (seperti Kafka, RabbitMQ, AWS SQS/SNS, dan sistem serupa), melibatkan layanan yang memublikasikan peristiwa atau pesan tanpa menunggu respons tertentu; hal ini memungkinkan satu atau lebih layanan lain untuk mengonsumsi dan bereaksi terhadap peristiwa tersebut secara independen dan sesuai dengan kecepatan pemrosesan masing-masing. Pilihan antara kedua pola komunikasi ini—yang diterapkan secara konsisten dan terencana di seluruh sistem—memiliki konsekuensi signifikan terhadap tingkat ketahanan dan keterikatan dari arsitektur yang dihasilkan, terlepas dari seberapa rapi dekomposisi layanan itu sendiri dilakukan.

Kecepatan Deployment dan Rilis

Dalam arsitektur monolitik, setiap deployment melibatkan pengiriman seluruh aplikasi, terlepas dari seberapa kecil perubahan yang sebenarnya dilakukan. Baik perbaikan bug satu baris pada pesan kesalahan maupun penambahan fitur baru yang signifikan, keduanya harus melalui alur kerja build, pengujian, dan deployment yang sama untuk keseluruhan sistem. Hal ini membawa konsekuensi nyata yang terdokumentasi dengan baik seiring berkembangnya aplikasi dan tim teknisnya: proses build memakan waktu lebih lama karena basis kode yang membesar, rangkaian pengujian membutuhkan waktu lebih lama untuk dijalankan seiring bertambahnya jumlah tes, dan—yang sangat krusial—cakupan dampak dari setiap deployment mencakup seluruh aplikasi. Sebuah bug yang muncul di bagian basis kode yang tidak terkait, atau kegagalan deployment di tengah jalan, berpotensi memengaruhi setiap fitur aplikasi secara bersamaan, bukan hanya fitur spesifik yang sedang diubah.

Dinamika ini menjadi semakin membatasi ketika semakin banyak insinyur yang bekerja pada basis kode monolitik yang sama secara bersamaan. Situasi di mana berbagai tim melakukan perubahan yang harus digabungkan, diuji bersama, dan dirilis dalam satu deployment terkoordinasi akan menimbulkan hambatan: perubahan dari satu tim dapat menghalangi atau menunda rilis tim lain yang tidak terkait, konflik merge dapat terjadi di antara tim yang mengerjakan bagian kode yang saling bersinggungan, serta meningkatnya kebutuhan akan koordinasi dan beban komunikasi—semata-mata untuk mengelola proses rilis itu sendiri—seiring bertambahnya jumlah tim yang berkontribusi.

Microservices menjawab tantangan ini secara langsung dengan memungkinkan setiap layanan dideploy secara independen. Tim yang bertanggung jawab atas Layanan Pembayaran dapat merilis perbaikan atau fitur baru untuk layanan tersebut berkali-kali dalam sehari tanpa perlu berkoordinasi dengan tim yang menangani Layanan Inventaris, tanpa harus menunggu kode dari tim lain yang tidak terkait untuk digabungkan dan diuji, serta tanpa risiko bahwa bug dari kode Layanan Inventaris yang sedang dikerjakan secara tidak sengaja ikut terilis bersamaan dengan perubahan pada Layanan Pembayaran. Independensi ini merupakan salah satu manfaat microservices berskala besar yang paling sering disebut dan benar-benar nyata; inilah alasan utama mengapa organisasi dengan banyak tim rekayasa yang mengerjakan produk yang sama merasa pendekatan ini sangat menarik.

Namun, perlu diakui secara jujur ​​bahwa manfaat ini berbanding lurus dengan skala organisasi. Tim rekayasa yang terdiri dari lima orang dan mengerjakan satu produk tidak akan mengalami kendala deployment yang berarti dalam arsitektur monolitik, karena tidak ada cukup banyak perubahan yang terjadi secara bersamaan untuk menimbulkan masalah koordinasi yang biasanya dapat diatasi melalui kemampuan deployment independen. Bagi tim kecil, argumen bahwa microservices memungkinkan "rilis lebih cepat" sebagian besar tidak relevan; justru, kompleksitas operasional tambahan dalam mengelola banyak layanan yang dideploy secara independen dapat membuat proses rilis menjadi lebih lambat dan lebih rentan terhadap kesalahan dalam praktiknya, alih-alih mempercepatnya.

Skalabilitas: Apa yang Sebenarnya Diselesaikan oleh Setiap Pendekatan

Dalam arsitektur monolitik, melakukan penskalaan untuk menangani peningkatan beban berarti menskalakan seluruh aplikasi sebagai satu kesatuan—yaitu menjalankan lebih banyak instans dari aplikasi lengkap yang sama di belakang load balancer. Jika satu fungsi spesifik dalam aplikasi (misalnya, pemrosesan gambar) membutuhkan sumber daya yang jauh lebih besar dibandingkan bagian aplikasi lainnya, maka melakukan penskalaan untuk memenuhi kebutuhan fungsi tersebut berarti menjalankan lebih banyak instans dari keseluruhan monolit, termasuk bagian-bagian aplikasi yang sebenarnya tidak sedang mengalami beban berat. Hal ini tidak efisien dalam aspek yang spesifik dan dapat diukur, yaitu kita membayar dan menyediakan kapasitas untuk keseluruhan aplikasi demi menangani beban yang sebenarnya terkonsentrasi pada satu bagian kecil saja.

Microservices memungkinkan penskalaan yang independen dan bersifat granular, yaitu jika Image Processing Service mengalami beban berat sementara User Profile Service tidak, organisasi dapat menambah jumlah instans Image Processing Service yang berjalan secara khusus, tanpa perlu menyentuh User Profile Service sama sekali. Dalam lingkungan cloud dengan konfigurasi auto-scaling per layanan, hal ini dapat menghasilkan penghematan biaya infrastruktur yang signifikan dan pemanfaatan sumber daya yang lebih baik dibandingkan dengan menskalakan seluruh monolit secara seragam hanya untuk memenuhi kebutuhan satu fungsi yang paling intensif dalam penggunaan sumber daya.

Namun, penting untuk memahami secara tepat masalah apa yang sebenarnya diselesaikan oleh pendekatan ini, karena "skalabilitas" sering kali dijadikan alasan untuk menggunakan microservices dalam situasi di mana hambatan yang sebenarnya terjadi bukanlah masalah yang dapat diatasi secara signifikan oleh microservices. Sebuah monolit yang dirancang dengan baik agar bersifat stateless (tidak menyimpan data sesi di dalam memori instans server tertentu) sebenarnya sudah dapat diskalakan secara horizontal hingga tingkat yang sangat signifikan hanya dengan menjalankan lebih banyak instans di belakang load balancer—sebuah teknik yang telah memungkinkan aplikasi monolitik melayani traffic data dalam jumlah sangat besar jauh sebelum microservices menjadi pola yang banyak dibahas. Keunggulan spesifik dalam hal penskalaan yang ditawarkan oleh microservices adalah efisiensi penskalaan yang granular dan berbasis fungsi, bukan sekadar kemampuan penskalaan dalam pengertian umum yang secara mutlak tidak dimiliki oleh monolit yang dibangun dengan baik.

Manajemen Data dan Persoalan Database

Aplikasi monolitik biasanya menggunakan satu database bersama. Hal ini memiliki keuntungan signifikan yang sering kali kurang dihargai, yaitu konsistensi yang kuat dan transaksi yang sederhana dapat diperoleh secara praktis tanpa biaya tambahan. Jika suatu operasi perlu memperbarui saldo akun pengguna dan secara bersamaan membuat catatan pesanan—di mana kedua tindakan tersebut harus berhasil atau gagal secara bersamaan (alih-alih membiarkan sistem dalam keadaan tidak konsisten, misalnya saldo telah didebit namun pesanan tidak pernah dibuat)—sistem monolitik dengan satu database dapat membungkus kedua operasi tersebut dalam satu transaksi database, dan database itu sendiri menjamin sifat atomisitasnya. Melakukan kueri dan penggabungan data yang—dalam arsitektur microservices—akan mencakup beberapa domain berbeda (seperti laporan yang menggabungkan informasi pengguna, riwayat pesanan, dan status inventaris) dapat dilakukan melalui kueri SQL sederhana dengan operasi join antar-tabel dalam sistem monolitik.

Dalam arsitektur microservices, praktik standar yang sangat disarankan adalah agar setiap layanan memiliki database-nya sendiri, tanpa layanan lain diizinkan untuk mengakses atau melakukan kueri secara langsung ke database tersebut, jadi semua akses ke data suatu layanan harus melalui API layanan itu sendiri. Pola "satu database per layanan" inilah yang sebenarnya memungkinkan kemampuan penerapan secara independen dan fleksibilitas teknologi, yaitu faktor-faktor utama yang membuat microservices bernilai. Jika setiap layanan berbagi satu database dengan skema tetap, mengubah skema tersebut demi kebutuhan satu layanan akan berisiko merusak layanan lain yang bergantung padanya, sehingga memunculkan kembali masalah keterikatan yang erat dan kebutuhan deployment terkoordinasi—masalah-masalah yang justru ingin dihilangkan dengan mengadopsi microservices.

Biaya deployment pola ini cukup besar dan—menurut penilaian jujur ​​banyak insinyur yang telah menjalani migrasi nyata ke arsitektur microservices—merupakan salah satu aspek tersulit untuk diterapkan dengan benar dalam keseluruhan arsitektur tersebut. Operasi yang pada sistem monolitik merupakan satu transaksi database atomik akan berubah menjadi transaksi terdistribusi yang melibatkan berbagai layanan dan database; transaksi semacam ini tidak dapat dibuat atomik dengan cara sederhana yang sama, karena transaksi database tidak bisa mencakup dua sistem database yang sepenuhnya terpisah. Pola seperti Saga (yang memecah transaksi terdistribusi multi-tahap menjadi serangkaian transaksi lokal di dalam setiap layanan, masing-masing disertai tindakan kompensasi untuk membatalkan perubahan jika tahap berikutnya gagal) hadir khusus untuk mengatasi masalah ini. Namun, pola-pola tersebut jauh lebih kompleks untuk dirancang, diimplementasikan, dan dipahami dibandingkan transaksi database konvensional, serta umumnya mengorbankan konsistensi ketat demi konsistensi akhir; artinya, sistem akan mencapai kondisi konsisten, namun tidak serta-merta pada saat yang sama ketika operasi tersebut dimulai.

Demikian pula, laporan atau kueri yang membutuhkan data lintas domain beberapa layanan tidak bisa lagi dilakukan melalui operasi join database yang sederhana. Hal ini biasanya mengharuskan kita untuk memanggil API dari berbagai layanan lalu menggabungkan hasilnya dalam kode aplikasi, atau memelihara read model terpisah yang dirancang khusus (terkadang diisi melalui pola berbasis kejadian seperti CQRS—Command Query Responsibility Segregation) untuk mengagregasi data dari berbagai layanan guna mendukung kueri lintas domain tersebut secara efisien. Kedua pendekatan ini menambah kompleksitas nyata dalam perancangan dan implementasi—kompleksitas yang tidak ada pada sistem monolitik dengan satu database bersama.

Isolasi Kegagalan dan Ketahanan

Pada arsitektur monolitik yang diterapkan secara kurang tepat, bug parah di satu bagian aplikasi saja—seperti pengecualian yang tidak tertangani, kebocoran memori, atau infinite loop—berpotensi melumpuhkan seluruh proses. Akibatnya, semua fitur aplikasi menjadi tidak dapat diakses secara bersamaan, termasuk fitur-fitur yang sama sekali tidak terkait dengan penyebab kegagalan tersebut. Ini adalah pola kegagalan yang paling sering disebut sebagai kelemahan utama arsitektur monolitik—dan memang benar demikian. Namun, perlu dicatat bahwa arsitektur monolitik yang dirancang dengan baik—yang menjalankan beberapa instans replika di belakang load balancer dengan pemeriksaan kesehatan yang memadai—dapat memitigasi risiko ini secara signifikan: jika satu instans mengalami crash, load balancer akan mengalihkan lalu lintas ke instans lain yang sehat sementara instans yang gagal tersebut melakukan restart.

Microservices menawarkan isolasi kegagalan yang nyata pada tingkat proses, yaitu jika Recommendation Service mengalami crash atau tidak merespons, Checkout Service, User Authentication Service, dan bagian sistem lainnya pada prinsipnya dapat terus beroperasi secara normal. Hal ini dimungkinkan karena layanan-layanan tersebut berjalan sebagai proses yang sepenuhnya terpisah, tanpa berbagi memori ataupun domain kegagalan yang sama. Pengguna mungkin tidak mendapatkan rekomendasi yang dipersonalisasi untuk sementara waktu, namun mereka tetap dapat menelusuri produk, menambahkan barang ke keranjang belanja, dan menyelesaikan pembelian.

Poin penting yang sering kali terlewatkan adalah bahwa manfaat isolasi kegagalan ini hanya dapat terwujud jika arsitektur dirancang secara khusus untuk tetap berfungsi secara terbatas namun stabil saat terjadi kegagalan pada dependensi—dan hal ini tidak terjadi secara otomatis hanya karena sistem menggunakan arsitektur microservices. Jika Checkout Service melakukan panggilan sinkron ke Recommendation Service tanpa menerapkan mekanisme timeout, fallback, dan circuit breaker untuk menangani situasi di mana panggilan tersebut gagal atau macet, maka proses penanganan permintaan pada Checkout Service itu sendiri akan ikut macet atau gagal bersamaan dengan Recommendation Service. Dengan kata lain, kegagalan satu layanan merambat menjadi kegagalan layanan lainnya, sehingga membatalkan manfaat isolasi yang justru menjadi alasan utama pemisahan layanan tersebut sejak awal. Membangun microservices yang benar-benar tangguh menuntut penerapan pola-pola secara sengaja—seperti timeout, retry dengan backoff, circuit breaker, dan graceful degradation—pada setiap panggilan antar-layanan; ini merupakan disiplin dan upaya rekayasa yang substansial namun kerap diremehkan, sesuatu yang tidak perlu dipikirkan dengan cara serupa oleh sistem monolitik yang berkomunikasi melalui panggilan fungsi dalam proses.

Kompleksitas Pengujian

Pengujian aplikasi monolitik, secara relatif, tergolong sederhana. Unit test menguji fungsi dan kelas secara individual dan terisolasi. Integration test dapat menjalankan seluruh aplikasi (atau sebagian besarnya) dalam satu proses pengujian, menghubungkannya ke database uji, dan memverifikasi bahwa berbagai bagian sistem bekerja sama dengan benar—karena semuanya benar-benar berjalan bersama dalam proses yang sama, serta mengeksekusi jalur kode yang persis sama dengan yang akan berjalan di lingkungan produksi. End-to-end test yang memverifikasi alur kerja pengguna secara menyeluruh di berbagai fitur aplikasi juga sama sederhananya untuk dibuat, karena hanya ada satu aplikasi yang perlu dijalankan dan diajak berinteraksi.

Pengujian arsitektur microservices jauh lebih kompleks, karena alasan yang bersifat struktural dan bukan sekadar kebetulan. Melakukan unit test pada layanan individual secara terisolasi tetap sederhana dan tidak jauh lebih sulit dibandingkan pada aplikasi monolitik. Namun, memverifikasi bahwa beberapa layanan bekerja sama dengan benar—misalnya, memastikan Order Service dan Inventory Service berkoordinasi dengan tepat saat pesanan dibuat—memerlukan salah satu dari dua hal, yaitu menjalankan beberapa layanan nyata secara bersamaan di lingkungan pengujian (yang secara operasional rumit untuk disiapkan dan lambat untuk dijalankan) atau menggunakan versi mock atau stub dari layanan yang bergantung (yang menimbulkan risiko perilaku mock menyimpang dari perilaku layanan nyata seiring waktu, sehingga menghasilkan pengujian yang lolos padahal integrasi sebenarnya akan gagal). Contract testing—sebuah pola pengujian yang dikembangkan khusus untuk mengatasi celah ini, di mana layanan konsumen mendefinisikan ekspektasi terhadap API layanan penyedia, dan rangkaian pengujian layanan penyedia memverifikasi bahwa layanan tersebut terus memenuhi ekspektasi itu—telah menjadi praktik standar yang sangat berharga justru karena tantangan ini; namun, hal ini merupakan disiplin pengujian dan investasi perangkat tambahan yang tidak diperlukan oleh aplikasi monolitik.

Pengujian end-to-end yang mencakup seluruh alur kerja pengguna dalam arsitektur microservices bahkan lebih menuntut dari segi operasional; sering kali diperlukan lingkungan staging lengkap dengan setiap layanan yang telah di-deploy dan dikonfigurasi dengan benar agar dapat saling berkomunikasi, atau penggunaan perangkat virtualisasi layanan yang canggih—keduanya merupakan investasi infrastruktur dan proses nyata yang jauh melampaui kebutuhan pengujian aplikasi monolitik.

Beban Operasional dan Biaya Tersembunyi dari Microservices

Menjalankan arsitektur microservices di lingkungan produksi menuntut fondasi operasional dan infrastruktur yang jauh lebih canggih dibandingkan menjalankan arsitektur monolitik. Service discovery, yaitu mekanisme bagi suatu layanan untuk menemukan lokasi jaringan terkini dari layanan lain yang perlu dipanggil, terutama dalam lingkungan dinamis di mana instans layanan terus-menerus dibuat dan dihentikan akibat auto-scaling dan deployment—merupakan masalah yang tidak ada dalam arsitektur monolitik, di mana "memanggil bagian lain dari sistem" berarti memanggil fungsi dalam proses yang sama. Distributed tracing menjadi hal yang esensial, bukan sekadar pilihan, karena mendiagnosis penyebab lambat atau gagalnya permintaan pengguna mengharuskan penelusuran jalur permintaan tersebut melintasi belasan atau lebih layanan terpisah—yang masing-masing mencatat log secara independen—serta mengorelasikan semua informasi yang tersebar itu menjadi satu gambaran utuh yang koheren. Kemampuan inilah yang secara khusus disediakan oleh alat-alat seperti Jaeger, Zipkin, dan berbagai platform observability komersial, yang sekaligus mencerminkan investasi infrastruktur nyata serta kurva pembelajaran operasional yang berkelanjutan.

Keandalan jaringan menjadi prioritas utama dalam rekayasa sistem—sesuatu yang tidak menjadi perhatian utama pada arsitektur monolitik. Setiap panggilan antar-layanan yang dulunya merupakan panggilan fungsi dalam satu proses—yang andal, cepat, dan pada dasarnya pasti berhasil atau langsung memunculkan pengecualian yang jelas—kini berubah menjadi panggilan jaringan. Panggilan ini rentan terhadap latensi, timeout, kegagalan parsial, serta berbagai tantangan yang terdokumentasi dengan baik dalam konsep klasik "kesalahan asumsi komputasi terdistribusi". Para insinyur yang membangun microservices perlu menginternalisasi pola pikir yang sangat berbeda mengenai potensi kegagalan suatu operasi dibandingkan dengan mereka yang membangun sistem monolitik; perubahan pola pikir ini sungguh menantang serta membutuhkan waktu dan pengalaman nyata untuk dapat diterapkan secara menyeluruh di dalam organisasi rekayasa.

Investasi infrastruktur dan perangkat pendukung yang diperlukan untuk menjalankan microservices secara efektif—seperti orkestrasi kontainer (biasanya Kubernetes), service mesh untuk mengelola komunikasi antar-layanan, sistem logging dan pemantauan terpusat, serta alur kerja CI/CD yang cukup canggih untuk membangun, menguji, dan men-deploy puluhan atau ratusan layanan terpisah secara independen—tergolong sangat besar. Organisasi yang mengadopsi microservices tanpa terlebih dahulu membangun atau memiliki kematangan operasional ini sering kali justru berada dalam posisi yang lebih buruk dibandingkan jika mereka tetap menggunakan sistem monolitik, yaitu mereka menanggung beban kompleksitas penuh dari sistem terdistribusi tanpa memiliki perangkat dan praktik operasional yang memadai untuk mengelola kompleksitas tersebut secara efektif.

Fleksibilitas Teknologi

Pada dasarnya, sistem monolitik dibangun menggunakan satu bahasa pemrograman dan, umumnya, satu rangkaian framework serta library inti secara menyeluruh; mengubah pilihan teknologi dasar untuk keseluruhan aplikasi merupakan tugas sangat besar yang jarang berhasil diselesaikan oleh organisasi. Microservices memungkinkan setiap layanan dibangun menggunakan bahasa, framework, dan bahkan teknologi database apa pun yang paling sesuai dengan kebutuhan spesifik layanan tersebut: misalnya, layanan yang melakukan inferensi machine learning dengan beban komputasi tinggi mungkin dibangun menggunakan Python untuk memanfaatkan ekosistem data science-nya; layanan yang menangani pemrosesan transaksi dengan throughput sangat tinggi dan latensi rendah mungkin dibangun menggunakan Go atau Rust demi performa mentah yang unggul; sementara layanan yang terutama berfokus pada operasi CRUD cepat terhadap kumpulan data relasional mungkin menggunakan bahasa dan framework yang paling dikuasai dan produktif bagi tim developer-nya.

Fleksibilitas ini nyata dan memberikan nilai tambah yang sesungguhnya dalam kasus-kasus spesifik di mana berbagai bagian sistem memang memiliki kebutuhan teknis yang sangat berbeda. Namun, perlu dicatat bahwa manfaat ini juga merupakan salah satu alasan yang sering kali dilebih-lebihkan dalam praktik penerapan microservices. Faktanya, sebagian besar organisasi yang disurvei mengenai adopsi microservices mereka cenderung menggunakan jumlah bahasa dan framework yang terbatas untuk sebagian besar layanan mereka. Hal ini disebabkan oleh dua hal, yaitu pertama, keragaman teknologi yang tak terbatas menciptakan beban nyata dalam hal perekrutan, pelatihan, dan operasional (organisasi yang mendukung layanan produksi yang ditulis dalam enam bahasa berbeda membutuhkan keahlian, perangkat pendukung, dan kemampuan dukungan teknis untuk keenam bahasa tersebut); kedua, kebutuhan teknis spesifik yang benar-benar menjustifikasi pemilihan teknologi berbeda untuk suatu layanan ternyata lebih jarang ditemui dalam praktik dibandingkan dengan apa yang disiratkan oleh argumen teoretis.

Kapan Memilih Arsitektur Monolitik

Bagi produk tahap awal dan perusahaan rintisan di mana kebutuhan bisnis, model data, dan bahkan bentuk dasar produk masih terus digali serta kemungkinan besar akan berubah secara signifikan berdasarkan masukan pengguna dan respons pasar, arsitektur monolitik memungkinkan iterasi yang cepat dengan beban kerja tambahan yang rendah—sesuatu yang benar-benar dibutuhkan pada tahap perkembangan perusahaan ini. Menentukan batasan layanan sebelum kita benar-benar memahami domain bisnis secara mendalam untuk menetapkan batasan tersebut dengan tepat adalah kesalahan yang sering terjadi dan telah banyak didokumentasikan; arsitektur monolitik menunda keputusan tersebut hingga kita memiliki informasi yang memadai untuk mengambil keputusan yang tepat.

Bagi tim teknis berskala kecil, di mana beban koordinasi dan konflik saat penerapan yang sebenarnya ingin diatasi oleh arsitektur microservices—tidak terjadi dalam praktiknya (karena jumlah orang yang mengerjakan sistem secara bersamaan tidak cukup banyak untuk memicu konflik tersebut), kompleksitas operasional microservices kemungkinan besar justru akan menjadi beban alih-alih keuntungan, sehingga memperlambat kinerja tim dan bukannya mempercepatnya.

Bagi sistem dengan model data yang relatif sederhana namun saling terkait erat, di mana sebagian besar operasi benar-benar membutuhkan konsistensi yang kuat dan jaminan transaksi yang melintasi batasan layanan (yang dalam arsitektur microservices akan terpisah), penggunaan database tunggal yang digunakan bersama dalam arsitektur monolitik dapat menghindari kompleksitas besar terkait transaksi terdistribusi dan konsistensi eventual yang harus dihadapi jika operasi serupa dijalankan dalam arsitektur microservices.

Kapan Harus Memilih Microservices

Bagi organisasi rekayasa berskala besar dengan banyak tim otonom—di mana koordinasi deployment dan ketergantungan antar-tim telah menjadi hambatan nyata dan terukur terhadap kecepatan organisasi dalam merilis perubahan—kemampuan penerapan secara independen yang ditawarkan oleh microservices secara langsung mengatasi masalah organisasi yang nyata dan berdampak besar secara biaya, bukan sekadar masalah teoretis.

Untuk sistem dengan kebutuhan penskalaan yang sangat beragam di berbagai fungsinya—di mana bagian-bagian tertentu dari sistem mengalami pola beban yang sangat berbeda dan bervariasi secara independen dibandingkan bagian aplikasi lainnya—kemampuan penskalaan yang terperinci (per layanan) yang dimungkinkan oleh microservices dapat menghasilkan efisiensi infrastruktur dan penghematan biaya yang signifikan, yang tidak dapat dicapai oleh arsitektur monolitik dengan penskalaan seragam.

Bagi organisasi yang telah berinvestasi—atau siap berinvestasi—dalam kematangan operasional yang disyaratkan oleh microservices (seperti orkestrasi kontainer, distributed tracing dan observability, CI/CD yang canggih, serta disiplin organisasi terkait kontrak API dan kepemilikan layanan yang membuat sistem terdistribusi dapat dikelola dengan baik), arsitektur ini benar-benar dapat mewujudkan manfaat yang dijanjikannya. Sebaliknya, bagi organisasi yang belum memiliki kematangan operasional tersebut atau tidak sedang membangunnya secara serius bersamaan dengan proses migrasi, penerapan microservices kemungkinan besar justru akan menimbulkan lebih banyak masalah daripada menyelesaikannya, terlepas dari betapa menariknya arsitektur tersebut jika dilihat secara terpisah.

Jadi, pilihan antara arsitektur monolitik dan microservices tidak memiliki jawaban yang benar secara mutlak. Menganggapnya demikian—baik untuk satu pilihan maupun yang lain—mencerminkan kesalahpahaman mengenai hakikat arsitektur-arsitektur tersebut serta masalah spesifik yang dirancang untuk diatasi oleh masing-masing pendekatan.