Mengapa arsitektur berbasis message queue belakangan ini tampak kurang populer?

• Bahkan sampai awal 2010-an, banyak pembahasan tentang membangun sistem terdistribusi berbasis MQ, tetapi belakangan hampir tidak ada tulisan tentang itu
• Beberapa teori yang terpikir adalah sebagai berikut; mungkin salah satunya, atau saya penasaran apa pendapat orang lain
  • Redis menangani sebagian besar kasus penggunaan sekaligus caching, sehingga mengoperasikan message broker terpisah tidak lagi berguna. Kafka benar-benar bergerak ke skala yang sangat besar.
  • DB (dalam arti yang luas) menjadi jauh lebih baik dalam menangani pemrosesan berskala besar, sehingga pekerjaan yang "sementara" diproses di penyimpanan utama
  • Orang-orang menyadari bahwa arsitektur berbasis MQ tidak bekerja sebaik yang diharapkan, jadi sekarang mereka memakai pendekatan lain
  • Sebenarnya teknologi MQ kini sudah memasuki fase matang, jadi tidak lagi cukup menarik untuk dituliskan orang. Namun tetap digunakan secara luas

hnthrowaway_99

• Banyak arsitektur "populer" dari akhir 2000-an sampai awal 2010-an akhirnya menghilang setelah orang sadar akan fakta bahwa "Anda bukan Google. Perusahaan Anda tidak akan pernah menjadi Google"
• Pada masa itu ada dorongan kuat untuk "membangun seperti perusahaan besar yang sukses membangunnya"
• Namun setelah itu, banyak orang menyadari bahwa 99% perusahaan tidak membutuhkan kompleksitas tersebut
• Karena hardware dan database standar menjadi jauh lebih baik, semakin sedikit perusahaan yang membutuhkan "Scalability Trick" seperti itu
• Ambang saya untuk bertanya "adakah alasan mengapa kita tidak bisa melakukan semua ini dengan Postgres?" sekarang jauh lebih tinggi dibanding 10 tahun lalu
• Komentar-komentar balasan pada komentar ini
  • Sekarang ada mesin tunggal yang jauh lebih besar dan bisa dipakai dengan biaya yang wajar. Dulu perlu klaster kecil, tetapi sekarang satu sistem saja bisa menangani banyak workload yang beragam
  • Sejujurnya, saya pernah ikut beberapa proyek di Google untuk menghapus queue. Jadi mungkin keadaannya bahkan lebih dari sekadar menurun popularitasnya

biglain

• Ini sinis, tetapi menurut saya arsitektur MQ dan blog tentangnya adalah bentuk "Resume Driven Development". Padahal kenyataannya pekerjaan yang dilakukan bahkan bisa dijalankan di satu laptop tanpa perlu berkembang melampaui monolit.
• Mungkin orang-orang inilah yang membangun bencana microservice seperti mimpi buruk yang menghabiskan biaya AWS puluhan juta won per bulan
• Dan sekarang, orang-orang yang "memprioritaskan pencapaian teknis untuk karier mereka, alih-alih menyelesaikan masalah bisnis nyata dengan cara yang praktis" sedang menggembar-gemborkan AI dan menulis blog tentang itu

tuckerconnelly

• Baru-baru ini kami beralih kembali ke monolit karena microservice terlalu kompleks dan terlalu banyak kode duplikat. Tanpa microservice, kebutuhan akan message queue pun berkurang
• Untuk pekerjaan asinkron, saya pernah memakai RabbitMQ di satu proyek, tetapi rasanya terlalu tua dan terlalu over-engineered
• Dan banyak tool di sekitarnya (Celery) juga tidak sebagus tool modern yang dibangun di sekitar Redis (bullmq)
• Untuk proses bertingkat bergaya DAG, saya lebih suka menangani semuanya dalam satu pekerjaan besar jika memungkinkan, atau membaginya ke dalam sejumlah kecil pekerjaan
• Jika benar-benar membutuhkan DAG, ada tool yang memang dibuat khusus untuk itu (Airflow). Tetapi saya dengar debugging masalah di sana sulit, jadi sebaiknya dihindari kalau bisa
• Saya tetap bertahan pada single node karena arsitektur multi-node Redis menurut saya sangat terlalu kompleks dan bermasalah untuk scale, tetapi sharding manual tidak masalah bagi saya dan berjalan baik
• Komentar kypro untuk tulisan ini
  • Berdasarkan pengalaman saya, monolit bukan mengurangi kompleksitas, melainkan hanya memindahkannya
  • Masalah terbesar monolit adalah karena pemisahan concern antar domain tidak jelas dan eksplisit, seiring waktu codebase monolit mudah berubah menjadi kekacauan spaghetti code yang sangat saling terhubung
  • Ini terutama benar saat membangun proyek besar dengan banyak developer, apalagi jika banyak developer tidak memahami seluruh kompleksitas domain dari kode yang mereka sentuh
  • Monolit cocok untuk proyek kecil dengan sedikit developer, tetapi selain itu, dalam beberapa tahun kebanyakan orang akan menyesal telah membangun monolit
  • Saya juga tidak setuju soal poin kode duplikat. Jika memakai bahasa yang sama dan berbagi package antar proyek, saya tidak melihat kenapa itu menjadi masalah besar
  • Bagaimanapun, saat bekerja dengan microservice saya belum pernah mengalami masalah seperti ini
  • Saya juga ingin mempertanyakan apakah microservice rata-rata benar-benar lebih kompleks daripada monolit
  • Hal yang paling saya sukai dari arsitektur microservice adalah betapa mudahnya memahami dan berkontribusi pada microservice individual
  • Arsitektur dan provisioning microservice mungkin lebih kompleks, tetapi dari sudut pandang developer yang mengerjakannya, dibanding monolit, microservice jauh lebih sederhana untuk dikerjakan

democracy

• Saya rasa gagasan ini benar: "Teknologi MQ kini sudah matang, jadi tidak lagi cukup menarik untuk ditulis, tetapi masih digunakan secara luas"
• Arsitektur berbasis messaging sangat populer
• Komentar-komentar untuk tulisan ini
  • casper14 : Setuju. Ini cuma sudah menjadi satu tool saja. Sama seperti tidak ada lagi orang yang menulis tentang cara memakai virtual machine di cloud
  • bwhaley : Ini jawaban yang tepat. Saya berani bilang hampir semua sistem terdistribusi yang berjalan dalam skala besar memakai message queue dalam kapasitas tertentu
  • ipsum2 : Ini sangat mungkin. Dulu posting tentang menulis ulang Angular ke React populer, tetapi sekarang semua orang tinggal memakai React, atau menulis tentang rewrite React ke Vue

busterarm

• Saya akan memberi jawaban yang mungkin tidak populer
• Queue, stream, dan Pub/Sub adalah konsep yang tidak benar-benar dipahami oleh kebanyakan engineer
  • Mereka tidak tahu kapan dibutuhkan, tidak tahu cara memakainya dengan benar, dan memakainya untuk tujuan yang salah
  • Saya masih bekerja dengan semua yang disebut di atas (SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub)
• Saya bekerja di perusahaan yang hanya merekrut engineer paling "brilian" dari 3~4 universitas teratas di Amerika Utara, dan hampir semua engineer menjadikan ini pekerjaan pertama mereka
• Engineer kami telah melakukan kegilaan seperti berikut:
  • Mendorong puluhan ribu pesan berukuran 100MB ke RabbitMQ dalam sekejap lalu heran kenapa sistemnya meledak
  • Secara umum mengirim pesan berukuran cukup besar lewat RabbitMQ meskipun semua peringatan mengatakan jangan lakukan itu
  • Memulai proyek baru pada RabbitMQ versi terbaru tahun 2024 lalu mencoba memakai classic queue
  • Membuat quorum queue tanpa kebijakan replikasi, atau secara harfiah tidak melakukan apa pun untuk membuat HA
  • Mengekspos cluster ke internet dengan user manajemen guest/guest
  • Arsitek paling senior di organisasi mendeklarasikan pola arsitektur baru, mengadakan pertemuan seluruh organisasi, dan melakukan demo
    • Memuji kebajikan/pola baru berupa memasukkan pesan ke queue lalu membuat backchannel agar konsumen kedua bisa memproses pesan dalam queue secara on-demand (dan dengan demikian itu bukan queue lagi)
    • Dan selain saya, tidak ada yang berkata, "mengapa pesan yang harus diproses berurutan dimasukkan ke queue?"; lalu 'pola' itu pun menetap!
  • Menggunakan Kafka sebagai message queue default
  • Mengirim data dari data center pusat ke data center yang tersebar di seluruh dunia, lalu menerapkan global lock pada objek dan semua operasi sampai tiap data center tujuan mengonfirmasi telah menerima objek yang diperbarui. Mereka mengklaim proses ini asinkron karena datanya dikirim bersama request AJAX
• Hasilnya, orang-orang tetap berhasil meski sebenarnya tidak perlu melakukan sesuatu yang begitu hebat. Jadi tool ini disalahgunakan, dipakai berlebihan, atau malah kurang dimanfaatkan
• Di tempat yang memakainya dengan baik, Anda mungkin tidak akan mendengar banyak cerita tentangnya
• Fakta penting: di organisasi kami ada lebih dari 30 microservice per engineer. Tolong bunuh saya. Daripada bekerja di organisasi lain yang punya ribuan microservice dalam monorepo raksasa, saya benar-benar lebih memilih jadi Kurt Cobain
• Komentar-komentar untuk tulisan ini
  • zug_zug : Untuk mendukung teori ini dengan data nyata
    • Saya pernah bekerja di startup di New York yang memakai Akka (queueing berbasis event di Scala)
    • Kenapa begitu? Apakah karena manajer dari pekerjaan sebelumnya pernah "menyelamatkan" perusahaannya "saat semuanya lambat" dengan cara ini, lalu mewajibkannya di pekerjaan barunya?
    • Pekerjaan seperti apa yang sebenarnya membutuhkan queueing? Hanya menampilkan 401k karyawan lewat website, membiarkan mereka menyesuaikan alokasi aset, dan mengirim beberapa ratus email per hari
    • Seperti yang bisa diduga, hampir tidak ada orang yang login ke website 401k itu
    • Setelah sekitar setahun bekerja di sana, saya sadar server terus-menerus salah konfigurasi dan pada dasarnya concurrency untuk request web adalah 0
    • (Mereka tidak menyadarinya karena 2 server produksi selalu bisa menangani seluruh traffic yang dibutuhkan)
    • Akhirnya Akka dihapus karena menambah kompleksitas yang tidak perlu dan tidak dibutuhkan
    • Bulan lalu, perusahaan ini menjalani putaran pendanaan lain dengan opsi cash-out, valuasinya jelas naik, dan tampaknya mereka masih baik-baik saja
  • scary-size : Ini benar-benar tidak terdengar seperti hanya merekrut engineer yang "brilian", ya?
  • roncesvalles : Kedengarannya tidak ada proses design review. Dan kalau saya, saya lebih suka merekrut developer dengan pengalaman 2-5 tahun dari universitas yang tidak terkenal daripada lulusan kampus ternama. Jumlah hal yang dipelajari dan pertumbuhan software engineer dalam 5 tahun pertama kariernya luar biasa besar, mungkin lebih banyak daripada sisa kariernya digabung.

burutthrow

• Saya rasa MQ sudah cukup terkomoditisasi
• Jika Anda membeli Confluent, RedPanda, atau MSK sebagai layanan, Anda tidak perlu mengelola Kafka sendiri
• Change Data Capture (CDC) juga sudah sangat bagus dan menjadi arus utama. Menulis data ke RDBMS lalu menangkap perubahan data dan menyebarkannya ke sistem lain kini relatif mudah
• Misalnya, pattern seperti ini berarti orang tidak menulis tentang Kafka, karena message queue hanyalah backbone yang dipakai sistem CDC untuk mengirim pesan
• Arsitektur seperti ini jelas masih ada dan memenuhi batasan kebanyakan organisasi
• Jika ada queue seperti Kafka yang write-once read-many, itu bisa dipakai untuk mengekspos API ke bagian lain organisasi. Banyak perusahaan memakai pattern ini untuk mencampur dan memakai data lintas banyak tim
• Tim kecil yang memiliki banyak microservice terasa seperti developer yang berorientasi pada resume, tetapi di perusahaan dengan lebih dari 100 engineer, pattern ini masuk akal

angarg12

• MQ adalah tool dalam toolbox sistem terdistribusi. Saat tepat digunakan, ia bekerja dengan sangat baik
• Jika teori Anda benar, saya rasa yang paling tepat adalah ini: "Orang biasanya menulis posting blog tentang hal yang baru dan berkilau"
• Saya pribadi selalu memakai queue dalam desain, terutama untuk memindahkan data antar sistem berbeda yang sangat ter-decouple
• Satu-satunya kesulitan yang pernah saya alami adalah ketika sistem upstream mengisi ulang data selama 7 hari dan queue tersumbat oleh request lama
  • Jika dijalankan normal, memproses semua data itu akan memakan waktu lebih dari 100 jam, dan latensi data baru juga akan meningkat drastis
  • Solusinya adalah membuang queue secara manual dan mengisi ulang data terbaru yang hilang secara manual
• Kita harus berhati-hati terhadap ukuran queue yang tak terbatas, tetapi menurut saya ini tetap tool yang hebat

rossdavidh

• MQ dalam Gartner Hype Cycle kini
  • telah melewati 'Peak of inflated expectations'
  • telah melewati 'trough of disillusinment'
  • dan sedang menuju 'Slope of Enlightment' bahkan 'plateau of productivity'

robertclaus

• Sangat menarik bahwa komentar "jelas kita semua masih memakai message queue dan worker, kita hanya tidak menulis tentangnya" tenggelam di belakang perdebatan tentang microservice dan skalabilitas nyata
• Engineer junior yang membaca thread ini bisa mendapat kesan yang salah bahwa mereka tidak lagi seharusnya memindahkan komputasi berat dari web server ke worker

pm90

• Tulisan blog tentang teknologi ini berkurang karena teknologinya sudah membosankan
• Dan ini hal yang baik. Misalnya dokumentasi resmi RabbitMQ sekarang jauh lebih baik dan sangat berguna
• Orang-orang memakainya sebagai andalan seperti mereka memakai Postgres/MySQL
• Anda juga tidak membutuhkan teknik yang mengagumkan untuk merancang arsitektur dan sebagainya
• Saya suka software yang membosankan: "I love boring software"

slowmovintarget

• Sebagian besar arsitektur seperti ini dulu berjalan di data center perusahaan
• Setelah berpindah ke cloud dan membangun layanan kecil tanpa state (dengan munculnya SPA), kebutuhan akan sistem event-driven bertahap yang rumit berkurang
• Misalnya di AWS, cukup memakai SQS dan sedikit SNS, atau Kinesis untuk beberapa hal. Di sini MQ tidak lagi menjadi pusat desain
• Arsitektur berbasis MQ bagus untuk pemrosesan data, tetapi tidak cocok untuk website interaktif; jika kebanyakan orang membangun website interaktif, pilihannya memang jadi tampak terbatas
• Saya masih merancang sistem event untuk pemrosesan data (terutama untuk data bisnis immutable ketika ada fakta baru tetapi seharusnya kita "salah" atau seharusnya mengetahui informasi lain pada titik waktu sebelumnya)
• Tetapi untuk sebagian besar aplikasi... tidak diperlukan

mannyv

• Seluruh backend kami berbasis queue
• Jika sesuatu bersifat asinkron dan tidak membutuhkan waktu respons cepat, gunakan queue. Mudah, andal, dan queue bisa menggerakkan lambda
• Selain itu, queue memudahkan pengumpulan metrik dan data performa.
  • Saat beban tinggi, queue bisa menggembung hingga jutaan pesan lalu menyusut seiring waktu,
  • atau Anda bisa membuat ratusan lambda sesuai kebutuhan untuk memproses semua pesan

vishnugupta

• Dari pengalaman saya, MQ telah diabstraksikan, bukan menghilang
• Misalnya antrian untuk SQS + polling telah menjadi proses yang memanggil server lebih sedikit. Di suatu tempat masih ada message queue, hanya saja tidak diekspos
• AWS SNS, yang satu tingkat lebih abstrak daripada SQS, telah menjadi sangat kaya fitur sampai pada dasarnya bisa menggantikan SQS
• Selain itu, karena streaming telah menjadi teknologi yang sangat stabil, use case yang sebelumnya memakai queue sebagai stream pipe telah bermigrasi ke streaming murni

memset

• Bisa jadi karena lambda (cloud function) menjadi lebih populer dan didukung di berbagai platform
• Jika Anda menambahkan sesuatu ke queue, pada akhirnya Anda tetap harus mengambilnya dari queue dan memprosesnya. Lambda melakukan ini dalam satu invocation. Anda juga tidak perlu menjalankan atau menskalakan worker
• Saya rasa Kafka tetap populer karena dipakai sebagai penyimpanan data sementara dan punya ekosistem besar untuk mengonsumsi stream
• Saya pribadi banyak memakai queue dan sedang membangun alternatif open source untuk SQS. Saya penasaran apakah alternatif open source untuk lambda juga akan berguna

liampulles

• "Teknologi MQ kini sudah memasuki fase matang, jadi tidak lagi cukup menarik untuk ditulis orang. Namun tetap digunakan secara luas"
  • Ini benar. Menurut saya use case sederhana komunikasi asinkron dengan messaging Pub/Sub sederhana sangat berguna dan tidak terlalu sulit digunakan
• Kita (sebagai komunitas developer) sudah melewati event sourcing, jaringan kompleks, dan pembangunan skala yang tidak perlu. Artinya, kita sudah melewati siklus hype
• Tim kami memakai NATS untuk Pub/Sub asinkron dan Request/Response sinkron
  • Ini model berbasis command, dan kami punya tabel log besar yang berisi semua pesan yang kami kirim
  • Skema dan penggunaan pesan-pesan ini bersifat internal bagi tim kami, dan dihapus dari NATS setelah dipakai
  • Kami memakai at-least-once delivery dan mengharapkan message handler memiliki sifat idempoten
• Kami pernah mengalami satu atau dua masalah akibat konfigurasi NATS yang salah sehingga pesan diputar ulang atau hilang, tetapi secara keseluruhan sangat sukses, dan tim developer kami hanya terdiri dari 3 orang
• Menurut saya ini seperti Kubernetes. Jika Anda berpegang pada inti dasarnya dan tidak berusaha terlalu pintar, sistem ini bekerja dengan baik

[finnchoi]

Ada situasi yang memang tepat untuk menggunakan queue. Namun, pada sebagian besar skala dan pola penggunaan, memakai queue atau menjalankannya dalam konfigurasi cluster sering kali menambah kompleksitas dan tidak memberi banyak keuntungan dari sisi performa. Struktur rumit yang dibanggakan perusahaan besar, yang dibangun dengan mempertimbangkan skalabilitas dan data berskala besar, mungkin tidak akan pernah benar-benar menjadi pilihan yang tepat untuk sistem saya.

Teknologi baru yang menarik secara teknis dan arsitektur yang keren juga tetap perlu dipilih sebagai solusi yang tepat dengan mempertimbangkan masalah yang realistis. Dalam kebanyakan kasus, tidak ada data besar yang perlu diproses, dan sering kali PostgreSQL saja sudah cukup.

Kami menyadari masalah ini dan sedang mengembangkan DB dengan struktur sederhana yang mampu memproses data hingga skala TB pada satu node. Kami menyampaikannya dengan sedikit hati-hati, tetapi kami merekomendasikan Anda untuk mempertimbangkannya sebagai opsi lain.
Membuat data preseden hukum siap ditelusuri dengan cepat

[dakbutfly]

Secara umum, pendekatan prosedural lebih mudah dipahami, sedangkan cara MQ sering kali tidak langsung terasa intuitif atau sulit dipahami strukturnya. Di perusahaan, tingkat pengetahuan tiap orang sering kali tidak sama; dalam kondisi seperti ini, jika MQ digunakan dengan pemahaman yang keliru, hasilnya bisa menjadi neraka.

Menurut saya, ini bukan hanya soal MQ, tetapi masalah yang selalu muncul ketika teknologi apa pun yang menuntut tingkat pengetahuan tertentu diterapkan tanpa pendidikan yang memadai secara menyeluruh.

[nemorize]

PHP membuat MQ pada dasarnya wajib...

[halfenif]

Lumayan menohok!

Saat ini saya sedang mengerjakan sebuah Toy Project yang namanya mengandung Quee.

[kandk]

Sejujurnya, kalau 99% layanannya hanya untuk dioperasikan di dalam negeri, menurut saya semua itu tidak perlu..

[superwoou]

Bukankah yang penting bukan cakupan layanan, melainkan sifat layanannya / seberapa besar efisiensi biaya yang perlu dipertimbangkan?

[bus710]

Apakah karena prosedur pengambilan keputusan cenderung vertikal, maka pendekatan yang “berorientasi prosedur” lebih disukai atau dianggap lebih cocok?
Kalau tiap divisi dan tim terorganisasi secara longgar, saya penasaran apakah arsitektur yang tidak berorientasi prosedur bisa berjalan lebih lancar, dan karena itu penerapan antrean seperti ini juga bisa bekerja lebih baik.

[savvykang]

Sepertinya pengembangan yang didorong demi mempercantik CV adalah kata kunci yang menembus fenomena tren seperti ini.

[hyeonseokoh94]

Wah, ini ungkapan yang keren ya—pengembangan yang didorong oleh CV, ya..

[savvykang]

Produk saudaranya juga ada, yaitu pengembangan yang digerakkan oleh sensasi.