मैसेज क्यू-आधारित आर्किटेक्चर आजकल कम लोकप्रिय क्यों लगते हैं?

xguru · 2024-06-21T11:03:01+09:00

2010 के शुरुआती दौर तक MQ-आधारित distributed systems बनाने की बहुत चर्चा होती थी, लेकिन आजकल इस विषय पर ज़्यादा लेख नहीं दिखते मेरे मन में कुछ संभावित सिद्धांत हैं; इनमें से कौन सा सही है, या दूसरों की क्या राय है, यह जानना चाहता हूँ Redis अब ज़्यादातर use cases और caching तक संभाल लेता है, इसलिए अलग message broker चलाने का फायदा कम हो गया है। Kafka सच में बहुत बड़े scale की दिशा में चला गया। DB (व्यापक अर्थ में) बड़े पैमाने की processing कहीं बेहतर करने लगे हैं, इसलिए "अस्थायी" processing भी main datastore में ही होने लगी है लोगों को समझ आ गया कि MQ-आधारित आर्किटेक्चर उम्मीद के मुताबिक अच्छा काम नहीं करते, इसलिए अब दूसरे तरीके इस्तेमाल हो रहे हैं असल में MQ टेक्नोलॉजी अब maturity phase में पहुँच चुकी है, इसलिए लोग उस पर उतना लिखने लायक उत्साहित नहीं हैं। लेकिन यह अब भी व्यापक रूप से इस्तेमाल हो रही है hnthrowaway_99 2000 के दशक के आख़िरी हिस्से से 2010 के शुरुआती दौर तक कई "लोकप्रिय" आर्किटेक्चर आख़िरकार इस समझ के साथ गायब हो गए कि "आप Google नहीं हैं। आपकी कंपनी Google कभी नहीं बनने वाली" उस समय "जिस तरह सफल बड़ी कंपनियों ने बनाया, उसी तरह बनाना" एक बड़ी आकांक्षा थी लेकिन बाद में बहुत लोगों को समझ आया कि 99% कंपनियों को इतनी complexity की ज़रूरत ही नहीं होती hardware और standard databases बहुत बेहतर हो जाने के कारण, ऐसी "Scalability Trick" की ज़रूरत वाली कंपनियाँ लगातार कम होती जा रही हैं "क्या कोई वजह है कि हम यह सब Postgres से न करें?" — इसके लिए मेरी सीमा 10 साल पहले की तुलना में अब बहुत ऊँची हो गई है इस टिप्पणी पर आए जवाब अब उचित लागत पर बहुत बड़े single machines उपलब्ध हैं। पहले small cluster की ज़रूरत पड़ती थी, लेकिन अब एक single system भी कई तरह के workloads संभाल सकता है सच कहूँ तो, मैंने Google में queue हटाने वाले कई projects पर काम किया है। इसलिए शायद बात सिर्फ़ "कम लोकप्रिय" होने से भी आगे की है biglain थोड़ा cynical लग सकता है, लेकिन मेरे हिसाब से MQ आर्किटेक्चर और उस पर blogging काफी हद तक "Resume Driven Development" था। असल में ऐसे कामों के लिए, जिन्हें monolith से आगे बढ़ाने की ज़रूरत भी नहीं थी और जो एक laptop पर चल सकते थे शायद यही लोग हर महीने लाखों रुपये के AWS bills वाले nightmare microservice disasters भी बनाते थे "जो लोग practical तरीके से असली business problem हल करने से ज़्यादा technical achievements को career priority बनाते हैं" — वही लोग आजकल AI को hype करके ब्लॉग लिख रहे हैं tuckerconnelly हाल ही में microservices बहुत complex और duplicate code से भरे लगे, इसलिए monolith पर वापस गया। Microservices न हों तो message queue की ज़रूरत भी कम हो जाती है async jobs के लिए मैंने एक project में RabbitMQ इस्तेमाल किया, लेकिन वह बहुत पुराना और overengineered लगा और उसके आसपास के कई tools (Celery) भी Redis (bullmq) पर बने modern tools जितने अच्छे नहीं लगे multi-stage DAG-style processes के लिए, मैं जहाँ संभव हो एक बड़े job में सब कुछ करना या कम संख्या वाले jobs में बाँटना पसंद करता हूँ अगर सच में DAG चाहिए, तो उसके लिए खास तौर पर बने tools (Airflow) हैं। लेकिन सुना है कि उन्हें debug करना कठिन होता है, इसलिए जहाँ तक हो सके उनसे बचना बेहतर है मुझे Redis की multi-node architecture बेतुकी हद तक जटिल लगती है और scaling में दिक्कत देती है, इसलिए मैं single node पर टिका हुआ हूँ। लेकिन manual sharding मेरे लिए ठीक है और अच्छी तरह काम करती है इस लेख पर kypro की टिप्पणी मेरे अनुभव में monolith complexity को कम नहीं करता, बस उसे दूसरी जगह ले जाता है monolith की सबसे बड़ी समस्या यह है कि domains के बीच concerns साफ़ और explicitly अलग नहीं होते, इसलिए समय के साथ monolith codebase एक highly interconnected spaghetti code mess बन जाता है खासकर जब बहुत से developers के साथ large-scale project बना रहे हों, और कई developers उस code की domain complexity पूरी तरह समझते न हों monolith कम developers वाले छोटे projects के लिए ठीक है, लेकिन अन्यथा कुछ सालों में ज़्यादातर लोग monolith बनाने पर पछताएँगे duplicate code वाले point से भी मैं सहमत नहीं हूँ। अगर वही language इस्तेमाल हो रही है और projects के बीच packages share हो रहे हैं, तो यह इतना बड़ा issue क्यों है, समझ नहीं आता वैसे भी microservices पर काम करते हुए मुझे ऐसी समस्या कभी नहीं हुई और मैं यह भी सवाल उठाना चाहूँगा कि क्या microservices औसतन monolith से ज़्यादा complex होते हैं microservices architecture की सबसे पसंदीदा बात मेरे लिए यह है कि individual microservice को समझना और उसमें योगदान देना कितना आसान होता है architecture और provisioning ज़्यादा complex हो सकते हैं, लेकिन microservice पर काम करने वाले developer के नज़रिए से monolith की तुलना में काम करना काफ़ी आसान हो सकता है democracy मुझे लगता है यह बात सही है: "MQ टेक्नोलॉजी अब maturity phase में है, इसलिए उस पर लिखना उतना रोमांचक नहीं रहा, लेकिन यह अभी भी व्यापक रूप से इस्तेमाल हो रही है" messaging-आधारित architecture बहुत लोकप्रिय है इस लेख पर टिप्पणियाँ casper14 : सहमत। यह बस एक tool बन गया है। जैसे अब कोई cloud में virtual machines इस्तेमाल करने के तरीक़े पर लेख नहीं लिखता bwhaley : यही सही जवाब है। लगभग हर distributed system जो बड़े scale पर चलता है, किसी न किसी रूप में message queue का इस्तेमाल करता है ipsum2 : यह काफ़ी सम्भावित लगता है। पहले Angular को React में rewrite करने वाली posts लोकप्रिय थीं; अब लोग बस React इस्तेमाल करते हैं या React को Vue में rewrite करने पर लिखते हैं busterarm मैं शायद अलोकप्रिय जवाब देने जा रहा हूँ queue, streams और Pub/Sub ऐसे concepts हैं जिन्हें ज़्यादातर engineers ठीक से नहीं समझते उन्हें नहीं पता कब इनकी ज़रूरत है, इन्हें सही तरह कैसे इस्तेमाल करना है, और वे इनका उपयोग गलत जगह कर देते हैं मैं अब भी इन सबके साथ काम करता हूँ (SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub) मैं ऐसी कंपनी में काम करता हूँ जो उत्तर अमेरिका की शीर्ष 3~4 यूनिवर्सिटीज़ से सिर्फ़ सबसे "brilliant" engineers को hire करती है, और लगभग हर engineer की यह पहली नौकरी है हमारे engineers ने इस तरह की पागल चीज़ें की हैं: RabbitMQ में 100MB के दसियों हज़ार messages एक झटके में queue कर देना और फिर सोचना कि यह फट क्यों गया हर warning के बावजूद RabbitMQ पर काफ़ी बड़े messages भेजना 2024 के नवीनतम RabbitMQ version पर नया project शुरू करके classic queues इस्तेमाल करना replication policy के बिना quorum queues बनाना, या literal HA के लिए कुछ भी न करना management user को guest/guest पर छोड़कर cluster को internet पर expose करना संगठन का सबसे senior architect एक नया architecture pattern घोषित करता है, org-wide meeting बुलाता है और demo दिखाता है queue में message डालो, फिर एक backchannel बनाओ ताकि दूसरा consumer queue में पड़े message को on-demand process कर सके (और इस तरह वह अब queue रह ही नहीं जाती) और मेरे अलावा किसी ने यह नहीं पूछा, "ऐसे messages को queue में क्यों डाल रहे हो जिन्हें क्रम से process किया जाना चाहिए?" — और वह 'pattern' चल पड़ा! Kafka को default message queue की तरह इस्तेमाल करना central data center से दुनिया भर के distributed data centers में data भेजना, और हर target data center से updated object receive होने की पुष्टि होने तक object पर global lock और बाकी सब कुछ बनाए रखना। और क्योंकि data AJAX request के साथ भेजा गया, इसलिए दावा करना कि यह process asynchronous है नतीजतन, लोग बहुत बड़ी चीज़ें किए बिना भी काम चला लेते हैं। इसलिए tools का misuse, abuse और underuse तीनों होता है जहाँ ये tools सही तरह इस्तेमाल हो रहे हों, वहाँ शायद आपको उनकी कहानियाँ सुनाई भी न दें महत्वपूर्ण तथ्य: हमारे संगठन में प्रति engineer 30 से ज़्यादा microservices हैं। कृपया मुझे मार दो। एक और संगठन में, जहाँ एक विशाल monorepo के भीतर हज़ारों microservices हों, काम करने से बेहतर मैं सचमुच Kurt Cobain बनना पसंद करूँगा इस लेख पर टिप्पणियाँ zug_zug : इस सिद्धांत को real data से support करूँ तो मैंने न्यूयॉर्क में एक startup में काम किया था जो Akka (Scala की event-driven queueing) इस्तेमाल करता था ऐसा क्यों? क्या इसलिए कि पिछली नौकरी के किसी manager ने कहा था कि इस तरीके ने कंपनी को तब "बचाया" था जब "सब कुछ धीमा" था, और उसने नई नौकरी में भी यह अनिवार्य कर दिया? वहाँ queueing की ज़रूरत किस काम के लिए थी? बस website पर कर्मचारियों का 401k दिखाना, उन्हें asset allocation बदलने देना, और रोज़ कुछ सौ emails भेजना जैसा अपेक्षित था, लोग उस 401k website में शायद ही कभी login करते थे वहाँ लगभग एक साल काम करने के बाद मुझे पता चला कि servers लगातार misconfigured थे और मूल रूप से web requests के लिए concurrency 0 थी (यह इसलिए पकड़ में नहीं आया क्योंकि 2 production servers हमेशा ज़रूरी पूरा traffic संभाल लेते थे) अंत में Akka को हटा दिया गया क्योंकि वह बेवजह और अनावश्यक complexity बढ़ा रहा था पिछले महीने इस कंपनी ने cash-out option के साथ एक और funding round किया; स्पष्ट है valuation बढ़ी और लगता है कंपनी अब भी अच्छा कर रही है scary-size : यह तो वास्तव में "brilliant" engineers ही hire करने जैसा नहीं लगता? roncesvalles : लगता है design review process ही नहीं है। और मैं होता तो famous universities के graduates की जगह किसी अनजान कॉलेज से 2-5 साल के अनुभव वाले developers को hire करता। software engineer अपने career के पहले 5 साल में जितना सीखता और बढ़ता है, शायद उतना बाद के पूरे career में भी नहीं। burutthrow मुझे लगता है MQ काफ़ी हद तक commoditized हो चुका है अगर आप Confluent, RedPanda या MSK को service की तरह खरीद लें, तो Kafka खुद manage करने की ज़रूरत नहीं रहती Change Data Capture (CDC) भी अब बहुत अच्छा और mainstream हो चुका है। RDBMS में data लिखना और फिर change data capture करके उसे दूसरे systems तक फैलाना अब काफ़ी आसान है उदाहरण के लिए, message queue बस वह backbone रह जाता है जिसका उपयोग CDC system messages पहुँचाने के लिए करता है, इसलिए लोग सीधे Kafka के बारे में कम लिखते हैं ये architectures स्पष्ट रूप से अब भी मौजूद हैं और ज़्यादातर organizations की constraints पूरी करते हैं Kafka जैसी write-once, read-many queue होने पर इसे organization के दूसरे हिस्सों के लिए API expose करने में भी इस्तेमाल किया जाता है। कई कंपनियाँ इस pattern से अलग-अलग teams के बीच data share और remix करती हैं बहुत सारी microservices own करने वाली छोटी team resume-driven development जैसी लग सकती है, लेकिन 100+ engineers वाली company में यह pattern काफ़ी reasonable है angarg12 MQ distributed systems की toolbox में एक tool है। सही जगह पर यह शानदार काम करता है अगर तुम्हारा कोई सिद्धांत सच है, तो मुझे लगता है वह यह है: "लोग आमतौर पर नई और चमकदार चीज़ों पर ब्लॉग पोस्ट लिखते हैं" मैं व्यक्तिगत रूप से अपने designs में हमेशा queues इस्तेमाल करता हूँ, खासकर तब जब अलग systems के बीच, जिनमें coupling कम हो, data भेजना हो मुझे केवल एक दर्दनाक स्थिति मिली जब upstream system ने 7 दिन का data backfill कर दिया और queue पुराने requests से jam हो गई सामान्य execution में सारा data process करने में 100 घंटे से ज़्यादा लगते, और नए data की latency भी बहुत बढ़ जाती समाधान था queue को manually खाली करना और गायब हुए latest data को manually backfill करना unbounded queue size से सावधान रहना चाहिए, लेकिन फिर भी यह शानदार tool है rossdavidh MQ Gartner Hype Cycle में 'Peak of inflated expectations' पार कर चुका है 'trough of disillusionment' भी पार कर चुका है और अब 'Slope of Enlightenment' या शायद 'plateau of productivity' की ओर बढ़ रहा है robertclaus यह काफ़ी दिलचस्प है कि "स्पष्ट है कि हम सब अभी भी message queues और workers इस्तेमाल कर रहे हैं, बस उस पर लिख नहीं रहे" जैसी टिप्पणी microservices और वास्तविक scalability पर बहस के नीचे दब गई यह टिप्पणी पढ़ने वाला कोई junior engineer शायद गलत निष्कर्ष निकाल ले कि अब web server के भारी computation को worker पर ऑफलोड नहीं करना चाहिए pm90 इस tech के boring हो जाने की वजह से इससे जुड़े ब्लॉग पोस्ट कम हो गए हैं और यह अच्छी बात है। उदाहरण के लिए RabbitMQ की official documentation अब बहुत बेहतर और बहुत उपयोगी है लोग इसे उसी तरह core technology की तरह इस्तेमाल करते हैं जैसे Postgres/MySQL को architecture वगैरह design करने के लिए कोई चमत्कारी skill भी नहीं चाहिए मुझे boring software पसंद है — "I love boring software" slowmovintarget इन architectures में से ज़्यादातर enterprise data centers में चलते थे cloud में shift होने के बाद और छोटे stateless services बनने लगे (SPA के आने के साथ), तो complex multi-step event-driven systems की ज़रूरत कम हो गई उदाहरण के लिए AWS में SQS और थोड़ा SNS, या कुछ मामलों में Kinesis काफ़ी है। यहाँ MQ अब design का केंद्र नहीं रहता MQ-आधारित architectures data processing के लिए अच्छे हैं, लेकिन interactive websites के लिए उपयुक्त नहीं; और अगर ज़्यादातर लोग interactive websites बना रहे हैं, तो चुनाव काफ़ी स्पष्ट है मैं अब भी data processing के लिए event systems design करता हूँ (खासकर जब immutable business data में नए facts आएँ, या बाद में पता चले कि पहले किसी और जानकारी का पता होना चाहिए था) लेकिन अधिकांश apps में... इसकी ज़रूरत नहीं होती mannyv हमारा पूरा backend queue-आधारित है अगर कुछ asynchronous है और तेज़ response time की ज़रूरत नहीं, तो queue इस्तेमाल करो। यह आसान है, reliable है, और queue Lambda को drive कर सकती है queue इस्तेमाल करने से metrics और performance data इकट्ठा करना भी आसान हो जाता है भारी load के समय queue लाखों messages तक फूल सकती है और फिर समय के साथ घट सकती है या आप चाहें तो सैकड़ों Lambda instances बनाकर सारे messages process कर सकते हैं vishnugupta मेरे अनुभव में MQ abstract हो गया है, गायब नहीं हुआ उदाहरण के लिए SQS + polling वाली queue अब ऐसे process में बदल गई है जिसमें server को कम बार call करना पड़ता है। कहीं न कहीं message queue अब भी है, बस वह सीधे दिखती नहीं SQS से एक स्तर ऊपर का abstraction AWS SNS भी features में इतना समृद्ध हो गया है कि वह कई मामलों में SQS की जगह ले सकता है और streaming बहुत reliable technology बन चुकी है, इसलिए जो use cases queue को streaming pipe की तरह इस्तेमाल करते थे, वे streaming-only solutions पर migrate हो गए हैं memset शायद इसलिए भी कि Lambda (cloud functions) अधिक लोकप्रिय हो गई हैं और कई platforms पर supported हैं आप queue में कुछ डालते हैं तो अंततः उसे निकालकर process करना पड़ता है। Lambda एक invocation में यह काम कर देती है। साथ ही workers चलाने या scale करने की ज़रूरत भी नहीं रहती मुझे लगता है Kafka लोकप्रिय बना हुआ है क्योंकि इसे temporary datastore की तरह इस्तेमाल किया जाता है, और streams से collect करने के लिए इसका बड़ा ecosystem है मैं व्यक्तिगत रूप से queues काफ़ी इस्तेमाल करता हूँ और open source SQS alternative बना रहा हूँ। सोचता हूँ कि open source Lambda alternative भी उपयोगी होगा या नहीं liampulles "MQ टेक्नोलॉजी अब maturity phase में पहुँच चुकी है, इसलिए लोग उस पर उतना नहीं लिखते, लेकिन यह अब भी व्यापक रूप से उपयोग में है" यही सही है। simple Pub/Sub messaging का उपयोग करने वाले async communication के सरल use cases बहुत उपयोगी हैं और इस्तेमाल करने में भी बहुत कठिन नहीं हम (developer community के रूप में) event sourcing, complex networks और अनावश्यक scale-building के दौर से आगे बढ़ चुके हैं। यानी हम hype cycle से निकल चुके हैं हमारी team async Pub/Sub और sync Request/Response दोनों के लिए NATS इस्तेमाल करती है यह command-based model है और हमारे पास एक बहुत बड़ी log table है जिसमें हमारे भेजे गए सभी messages होते हैं schema और इन messages का उपयोग हमारी team के भीतर का मामला है, और इस्तेमाल के बाद वे NATS से हटा दिए जाते हैं हम at-least-once delivery करते हैं और message handlers से idempotency की अपेक्षा रखते हैं NATS की गलत configuration के कारण एक-दो बार messages replay हुए या messages छूट गए, लेकिन कुल मिलाकर यह बहुत सफल रहा, और हमारी development team सिर्फ़ 3 लोगों की थी मेरे हिसाब से यह Kubernetes जैसा है। Basics पर टिके रहो और ज़रूरत से ज़्यादा चालाक बनने की कोशिश मत करो, तो यह अच्छा काम करता है

(news.ycombinator.com)

49 पॉइंट द्वारा xguru 2024-06-21 | 11 टिप्पणियां | WhatsApp पर शेयर करें

2010 के शुरुआती दौर तक MQ-आधारित distributed systems बनाने की बहुत चर्चा होती थी, लेकिन आजकल इस विषय पर ज़्यादा लेख नहीं दिखते
मेरे मन में कुछ संभावित सिद्धांत हैं; इनमें से कौन सा सही है, या दूसरों की क्या राय है, यह जानना चाहता हूँ
- Redis अब ज़्यादातर use cases और caching तक संभाल लेता है, इसलिए अलग message broker चलाने का फायदा कम हो गया है। Kafka सच में बहुत बड़े scale की दिशा में चला गया।
- DB (व्यापक अर्थ में) बड़े पैमाने की processing कहीं बेहतर करने लगे हैं, इसलिए "अस्थायी" processing भी main datastore में ही होने लगी है
- लोगों को समझ आ गया कि MQ-आधारित आर्किटेक्चर उम्मीद के मुताबिक अच्छा काम नहीं करते, इसलिए अब दूसरे तरीके इस्तेमाल हो रहे हैं
- असल में MQ टेक्नोलॉजी अब maturity phase में पहुँच चुकी है, इसलिए लोग उस पर उतना लिखने लायक उत्साहित नहीं हैं। लेकिन यह अब भी व्यापक रूप से इस्तेमाल हो रही है

hnthrowaway_99

2000 के दशक के आख़िरी हिस्से से 2010 के शुरुआती दौर तक कई "लोकप्रिय" आर्किटेक्चर आख़िरकार इस समझ के साथ गायब हो गए कि "आप Google नहीं हैं। आपकी कंपनी Google कभी नहीं बनने वाली"
उस समय "जिस तरह सफल बड़ी कंपनियों ने बनाया, उसी तरह बनाना" एक बड़ी आकांक्षा थी
लेकिन बाद में बहुत लोगों को समझ आया कि 99% कंपनियों को इतनी complexity की ज़रूरत ही नहीं होती
hardware और standard databases बहुत बेहतर हो जाने के कारण, ऐसी "Scalability Trick" की ज़रूरत वाली कंपनियाँ लगातार कम होती जा रही हैं
"क्या कोई वजह है कि हम यह सब Postgres से न करें?" — इसके लिए मेरी सीमा 10 साल पहले की तुलना में अब बहुत ऊँची हो गई है
इस टिप्पणी पर आए जवाब
- अब उचित लागत पर बहुत बड़े single machines उपलब्ध हैं। पहले small cluster की ज़रूरत पड़ती थी, लेकिन अब एक single system भी कई तरह के workloads संभाल सकता है
- सच कहूँ तो, मैंने Google में queue हटाने वाले कई projects पर काम किया है। इसलिए शायद बात सिर्फ़ "कम लोकप्रिय" होने से भी आगे की है

biglain

थोड़ा cynical लग सकता है, लेकिन मेरे हिसाब से MQ आर्किटेक्चर और उस पर blogging काफी हद तक "Resume Driven Development" था। असल में ऐसे कामों के लिए, जिन्हें monolith से आगे बढ़ाने की ज़रूरत भी नहीं थी और जो एक laptop पर चल सकते थे
शायद यही लोग हर महीने लाखों रुपये के AWS bills वाले nightmare microservice disasters भी बनाते थे
"जो लोग practical तरीके से असली business problem हल करने से ज़्यादा technical achievements को career priority बनाते हैं" — वही लोग आजकल AI को hype करके ब्लॉग लिख रहे हैं

tuckerconnelly

हाल ही में microservices बहुत complex और duplicate code से भरे लगे, इसलिए monolith पर वापस गया। Microservices न हों तो message queue की ज़रूरत भी कम हो जाती है
async jobs के लिए मैंने एक project में RabbitMQ इस्तेमाल किया, लेकिन वह बहुत पुराना और overengineered लगा
और उसके आसपास के कई tools (Celery) भी Redis (bullmq) पर बने modern tools जितने अच्छे नहीं लगे
multi-stage DAG-style processes के लिए, मैं जहाँ संभव हो एक बड़े job में सब कुछ करना या कम संख्या वाले jobs में बाँटना पसंद करता हूँ
अगर सच में DAG चाहिए, तो उसके लिए खास तौर पर बने tools (Airflow) हैं। लेकिन सुना है कि उन्हें debug करना कठिन होता है, इसलिए जहाँ तक हो सके उनसे बचना बेहतर है
मुझे Redis की multi-node architecture बेतुकी हद तक जटिल लगती है और scaling में दिक्कत देती है, इसलिए मैं single node पर टिका हुआ हूँ। लेकिन manual sharding मेरे लिए ठीक है और अच्छी तरह काम करती है
इस लेख पर kypro की टिप्पणी
- मेरे अनुभव में monolith complexity को कम नहीं करता, बस उसे दूसरी जगह ले जाता है
- monolith की सबसे बड़ी समस्या यह है कि domains के बीच concerns साफ़ और explicitly अलग नहीं होते, इसलिए समय के साथ monolith codebase एक highly interconnected spaghetti code mess बन जाता है
- खासकर जब बहुत से developers के साथ large-scale project बना रहे हों, और कई developers उस code की domain complexity पूरी तरह समझते न हों
- monolith कम developers वाले छोटे projects के लिए ठीक है, लेकिन अन्यथा कुछ सालों में ज़्यादातर लोग monolith बनाने पर पछताएँगे
- duplicate code वाले point से भी मैं सहमत नहीं हूँ। अगर वही language इस्तेमाल हो रही है और projects के बीच packages share हो रहे हैं, तो यह इतना बड़ा issue क्यों है, समझ नहीं आता
- वैसे भी microservices पर काम करते हुए मुझे ऐसी समस्या कभी नहीं हुई
- और मैं यह भी सवाल उठाना चाहूँगा कि क्या microservices औसतन monolith से ज़्यादा complex होते हैं
- microservices architecture की सबसे पसंदीदा बात मेरे लिए यह है कि individual microservice को समझना और उसमें योगदान देना कितना आसान होता है
- architecture और provisioning ज़्यादा complex हो सकते हैं, लेकिन microservice पर काम करने वाले developer के नज़रिए से monolith की तुलना में काम करना काफ़ी आसान हो सकता है

democracy

मुझे लगता है यह बात सही है: "MQ टेक्नोलॉजी अब maturity phase में है, इसलिए उस पर लिखना उतना रोमांचक नहीं रहा, लेकिन यह अभी भी व्यापक रूप से इस्तेमाल हो रही है"
messaging-आधारित architecture बहुत लोकप्रिय है
इस लेख पर टिप्पणियाँ
- casper14 : सहमत। यह बस एक tool बन गया है। जैसे अब कोई cloud में virtual machines इस्तेमाल करने के तरीक़े पर लेख नहीं लिखता
- bwhaley : यही सही जवाब है। लगभग हर distributed system जो बड़े scale पर चलता है, किसी न किसी रूप में message queue का इस्तेमाल करता है
- ipsum2 : यह काफ़ी सम्भावित लगता है। पहले Angular को React में rewrite करने वाली posts लोकप्रिय थीं; अब लोग बस React इस्तेमाल करते हैं या React को Vue में rewrite करने पर लिखते हैं

busterarm

मैं शायद अलोकप्रिय जवाब देने जा रहा हूँ
queue, streams और Pub/Sub ऐसे concepts हैं जिन्हें ज़्यादातर engineers ठीक से नहीं समझते
- उन्हें नहीं पता कब इनकी ज़रूरत है, इन्हें सही तरह कैसे इस्तेमाल करना है, और वे इनका उपयोग गलत जगह कर देते हैं
- मैं अब भी इन सबके साथ काम करता हूँ (SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub)
मैं ऐसी कंपनी में काम करता हूँ जो उत्तर अमेरिका की शीर्ष 3~4 यूनिवर्सिटीज़ से सिर्फ़ सबसे "brilliant" engineers को hire करती है, और लगभग हर engineer की यह पहली नौकरी है
हमारे engineers ने इस तरह की पागल चीज़ें की हैं:
- RabbitMQ में 100MB के दसियों हज़ार messages एक झटके में queue कर देना और फिर सोचना कि यह फट क्यों गया
- हर warning के बावजूद RabbitMQ पर काफ़ी बड़े messages भेजना
- 2024 के नवीनतम RabbitMQ version पर नया project शुरू करके classic queues इस्तेमाल करना
- replication policy के बिना quorum queues बनाना, या literal HA के लिए कुछ भी न करना
- management user को guest/guest पर छोड़कर cluster को internet पर expose करना
- संगठन का सबसे senior architect एक नया architecture pattern घोषित करता है, org-wide meeting बुलाता है और demo दिखाता है
  - queue में message डालो, फिर एक backchannel बनाओ ताकि दूसरा consumer queue में पड़े message को on-demand process कर सके (और इस तरह वह अब queue रह ही नहीं जाती)
  - और मेरे अलावा किसी ने यह नहीं पूछा, "ऐसे messages को queue में क्यों डाल रहे हो जिन्हें क्रम से process किया जाना चाहिए?" — और वह 'pattern' चल पड़ा!
- Kafka को default message queue की तरह इस्तेमाल करना
- central data center से दुनिया भर के distributed data centers में data भेजना, और हर target data center से updated object receive होने की पुष्टि होने तक object पर global lock और बाकी सब कुछ बनाए रखना। और क्योंकि data AJAX request के साथ भेजा गया, इसलिए दावा करना कि यह process asynchronous है
नतीजतन, लोग बहुत बड़ी चीज़ें किए बिना भी काम चला लेते हैं। इसलिए tools का misuse, abuse और underuse तीनों होता है
जहाँ ये tools सही तरह इस्तेमाल हो रहे हों, वहाँ शायद आपको उनकी कहानियाँ सुनाई भी न दें
महत्वपूर्ण तथ्य: हमारे संगठन में प्रति engineer 30 से ज़्यादा microservices हैं। कृपया मुझे मार दो। एक और संगठन में, जहाँ एक विशाल monorepo के भीतर हज़ारों microservices हों, काम करने से बेहतर मैं सचमुच Kurt Cobain बनना पसंद करूँगा
इस लेख पर टिप्पणियाँ
- zug_zug : इस सिद्धांत को real data से support करूँ तो
  - मैंने न्यूयॉर्क में एक startup में काम किया था जो Akka (Scala की event-driven queueing) इस्तेमाल करता था
  - ऐसा क्यों? क्या इसलिए कि पिछली नौकरी के किसी manager ने कहा था कि इस तरीके ने कंपनी को तब "बचाया" था जब "सब कुछ धीमा" था, और उसने नई नौकरी में भी यह अनिवार्य कर दिया?
  - वहाँ queueing की ज़रूरत किस काम के लिए थी? बस website पर कर्मचारियों का 401k दिखाना, उन्हें asset allocation बदलने देना, और रोज़ कुछ सौ emails भेजना
  - जैसा अपेक्षित था, लोग उस 401k website में शायद ही कभी login करते थे
  - वहाँ लगभग एक साल काम करने के बाद मुझे पता चला कि servers लगातार misconfigured थे और मूल रूप से web requests के लिए concurrency 0 थी
  - (यह इसलिए पकड़ में नहीं आया क्योंकि 2 production servers हमेशा ज़रूरी पूरा traffic संभाल लेते थे)
  - अंत में Akka को हटा दिया गया क्योंकि वह बेवजह और अनावश्यक complexity बढ़ा रहा था
  - पिछले महीने इस कंपनी ने cash-out option के साथ एक और funding round किया; स्पष्ट है valuation बढ़ी और लगता है कंपनी अब भी अच्छा कर रही है
- scary-size : यह तो वास्तव में "brilliant" engineers ही hire करने जैसा नहीं लगता?
- roncesvalles : लगता है design review process ही नहीं है। और मैं होता तो famous universities के graduates की जगह किसी अनजान कॉलेज से 2-5 साल के अनुभव वाले developers को hire करता। software engineer अपने career के पहले 5 साल में जितना सीखता और बढ़ता है, शायद उतना बाद के पूरे career में भी नहीं।

burutthrow

मुझे लगता है MQ काफ़ी हद तक commoditized हो चुका है
अगर आप Confluent, RedPanda या MSK को service की तरह खरीद लें, तो Kafka खुद manage करने की ज़रूरत नहीं रहती
Change Data Capture (CDC) भी अब बहुत अच्छा और mainstream हो चुका है। RDBMS में data लिखना और फिर change data capture करके उसे दूसरे systems तक फैलाना अब काफ़ी आसान है
उदाहरण के लिए, message queue बस वह backbone रह जाता है जिसका उपयोग CDC system messages पहुँचाने के लिए करता है, इसलिए लोग सीधे Kafka के बारे में कम लिखते हैं
ये architectures स्पष्ट रूप से अब भी मौजूद हैं और ज़्यादातर organizations की constraints पूरी करते हैं
Kafka जैसी write-once, read-many queue होने पर इसे organization के दूसरे हिस्सों के लिए API expose करने में भी इस्तेमाल किया जाता है। कई कंपनियाँ इस pattern से अलग-अलग teams के बीच data share और remix करती हैं
बहुत सारी microservices own करने वाली छोटी team resume-driven development जैसी लग सकती है, लेकिन 100+ engineers वाली company में यह pattern काफ़ी reasonable है

angarg12

MQ distributed systems की toolbox में एक tool है। सही जगह पर यह शानदार काम करता है
अगर तुम्हारा कोई सिद्धांत सच है, तो मुझे लगता है वह यह है: "लोग आमतौर पर नई और चमकदार चीज़ों पर ब्लॉग पोस्ट लिखते हैं"
मैं व्यक्तिगत रूप से अपने designs में हमेशा queues इस्तेमाल करता हूँ, खासकर तब जब अलग systems के बीच, जिनमें coupling कम हो, data भेजना हो
मुझे केवल एक दर्दनाक स्थिति मिली जब upstream system ने 7 दिन का data backfill कर दिया और queue पुराने requests से jam हो गई
- सामान्य execution में सारा data process करने में 100 घंटे से ज़्यादा लगते, और नए data की latency भी बहुत बढ़ जाती
- समाधान था queue को manually खाली करना और गायब हुए latest data को manually backfill करना
unbounded queue size से सावधान रहना चाहिए, लेकिन फिर भी यह शानदार tool है

rossdavidh

MQ Gartner Hype Cycle में
- 'Peak of inflated expectations' पार कर चुका है
- 'trough of disillusionment' भी पार कर चुका है
- और अब 'Slope of Enlightenment' या शायद 'plateau of productivity' की ओर बढ़ रहा है

robertclaus

यह काफ़ी दिलचस्प है कि "स्पष्ट है कि हम सब अभी भी message queues और workers इस्तेमाल कर रहे हैं, बस उस पर लिख नहीं रहे" जैसी टिप्पणी microservices और वास्तविक scalability पर बहस के नीचे दब गई
यह टिप्पणी पढ़ने वाला कोई junior engineer शायद गलत निष्कर्ष निकाल ले कि अब web server के भारी computation को worker पर ऑफलोड नहीं करना चाहिए

pm90

इस tech के boring हो जाने की वजह से इससे जुड़े ब्लॉग पोस्ट कम हो गए हैं
और यह अच्छी बात है। उदाहरण के लिए RabbitMQ की official documentation अब बहुत बेहतर और बहुत उपयोगी है
लोग इसे उसी तरह core technology की तरह इस्तेमाल करते हैं जैसे Postgres/MySQL को
architecture वगैरह design करने के लिए कोई चमत्कारी skill भी नहीं चाहिए
मुझे boring software पसंद है — "I love boring software"

slowmovintarget

इन architectures में से ज़्यादातर enterprise data centers में चलते थे
cloud में shift होने के बाद और छोटे stateless services बनने लगे (SPA के आने के साथ), तो complex multi-step event-driven systems की ज़रूरत कम हो गई
उदाहरण के लिए AWS में SQS और थोड़ा SNS, या कुछ मामलों में Kinesis काफ़ी है। यहाँ MQ अब design का केंद्र नहीं रहता
MQ-आधारित architectures data processing के लिए अच्छे हैं, लेकिन interactive websites के लिए उपयुक्त नहीं; और अगर ज़्यादातर लोग interactive websites बना रहे हैं, तो चुनाव काफ़ी स्पष्ट है
मैं अब भी data processing के लिए event systems design करता हूँ (खासकर जब immutable business data में नए facts आएँ, या बाद में पता चले कि पहले किसी और जानकारी का पता होना चाहिए था)
लेकिन अधिकांश apps में... इसकी ज़रूरत नहीं होती

mannyv

हमारा पूरा backend queue-आधारित है
अगर कुछ asynchronous है और तेज़ response time की ज़रूरत नहीं, तो queue इस्तेमाल करो। यह आसान है, reliable है, और queue Lambda को drive कर सकती है
queue इस्तेमाल करने से metrics और performance data इकट्ठा करना भी आसान हो जाता है
- भारी load के समय queue लाखों messages तक फूल सकती है और फिर समय के साथ घट सकती है
- या आप चाहें तो सैकड़ों Lambda instances बनाकर सारे messages process कर सकते हैं

vishnugupta

मेरे अनुभव में MQ abstract हो गया है, गायब नहीं हुआ
उदाहरण के लिए SQS + polling वाली queue अब ऐसे process में बदल गई है जिसमें server को कम बार call करना पड़ता है। कहीं न कहीं message queue अब भी है, बस वह सीधे दिखती नहीं
SQS से एक स्तर ऊपर का abstraction AWS SNS भी features में इतना समृद्ध हो गया है कि वह कई मामलों में SQS की जगह ले सकता है
और streaming बहुत reliable technology बन चुकी है, इसलिए जो use cases queue को streaming pipe की तरह इस्तेमाल करते थे, वे streaming-only solutions पर migrate हो गए हैं

memset

शायद इसलिए भी कि Lambda (cloud functions) अधिक लोकप्रिय हो गई हैं और कई platforms पर supported हैं
आप queue में कुछ डालते हैं तो अंततः उसे निकालकर process करना पड़ता है। Lambda एक invocation में यह काम कर देती है। साथ ही workers चलाने या scale करने की ज़रूरत भी नहीं रहती
मुझे लगता है Kafka लोकप्रिय बना हुआ है क्योंकि इसे temporary datastore की तरह इस्तेमाल किया जाता है, और streams से collect करने के लिए इसका बड़ा ecosystem है
मैं व्यक्तिगत रूप से queues काफ़ी इस्तेमाल करता हूँ और open source SQS alternative बना रहा हूँ। सोचता हूँ कि open source Lambda alternative भी उपयोगी होगा या नहीं

liampulles

"MQ टेक्नोलॉजी अब maturity phase में पहुँच चुकी है, इसलिए लोग उस पर उतना नहीं लिखते, लेकिन यह अब भी व्यापक रूप से उपयोग में है"
- यही सही है। simple Pub/Sub messaging का उपयोग करने वाले async communication के सरल use cases बहुत उपयोगी हैं और इस्तेमाल करने में भी बहुत कठिन नहीं
हम (developer community के रूप में) event sourcing, complex networks और अनावश्यक scale-building के दौर से आगे बढ़ चुके हैं। यानी हम hype cycle से निकल चुके हैं
हमारी team async Pub/Sub और sync Request/Response दोनों के लिए NATS इस्तेमाल करती है
- यह command-based model है और हमारे पास एक बहुत बड़ी log table है जिसमें हमारे भेजे गए सभी messages होते हैं
- schema और इन messages का उपयोग हमारी team के भीतर का मामला है, और इस्तेमाल के बाद वे NATS से हटा दिए जाते हैं
- हम at-least-once delivery करते हैं और message handlers से idempotency की अपेक्षा रखते हैं
NATS की गलत configuration के कारण एक-दो बार messages replay हुए या messages छूट गए, लेकिन कुल मिलाकर यह बहुत सफल रहा, और हमारी development team सिर्फ़ 3 लोगों की थी
मेरे हिसाब से यह Kubernetes जैसा है। Basics पर टिके रहो और ज़रूरत से ज़्यादा चालाक बनने की कोशिश मत करो, तो यह अच्छा काम करता है

11 टिप्पणियां

finnchoi 2024-06-25

कुछ स्थितियों में queue की ज़रूरत उचित होती है। लेकिन अधिकांश scale और usage patterns में queue का उपयोग करना या cluster बनाकर उसे चलाना, complexity बढ़ाने के अलावा performance के लिहाज़ से भी अक्सर कोई बड़ा फ़ायदा नहीं देता। scalability और बड़े data को ध्यान में रखकर बनाए गए बड़े enterprise जिन जटिल architectures पर गर्व करते हैं, संभव है कि वे मेरे सिस्टम के लिए उपयुक्त बनने का समय कभी आए ही नहीं।

तकनीकी रूप से आकर्षक नई technologies और शानदार structures भी हों, तब भी वास्तविक समस्याओं पर विचार करके उपयुक्त solution चुनना ज़रूरी है। ज़्यादातर मामलों में न तो process करने के लिए इतना बड़ा data होता है, और कई बार PostgreSQL से ही काम हो जाता है।

हम इस समस्या को पहचानते हैं और एक ऐसे DB का development कर रहे हैं जो सरल architecture में single node पर TB स्तर के data को process कर सके। थोड़ी सावधानी के साथ ही सही, लेकिन हम इसे एक और option के रूप में देखने की सलाह देते हैं।
मिसाल संबंधी data को तेज़ी से searchable state में लाना

dakbutfly 2024-06-24

लोकप्रिय रूप से procedural approach को समझना आसान होता है, लेकिन MQ तरीका तुरंत सहज नहीं लगता या उसकी संरचना को समझने में कठिनाई होती है। कंपनियों में अक्सर सभी का knowledge level एक जैसा नहीं होता, और ऐसे में अगर अधूरी या गलत समझ के साथ MQ का इस्तेमाल किया जाए तो वह नरक जैसा बन सकता है.

मेरा मानना है कि यह सिर्फ MQ की समस्या नहीं है; बल्कि जिन तकनीकों के लिए एक निश्चित स्तर का ज्ञान चाहिए, उन्हें बिना समुचित training के लागू करने पर आम तौर पर ऐसी समस्याएँ पैदा होती ही हैं.

nemorize 2024-06-21

PHP में MQ लगभग अनिवार्य है...

halfenif 2024-06-21

चुभ गया!

अभी मैं एक Toy Project पर काम कर रहा हूँ, जिसमें Quee नाम शामिल है।

kandk 2024-06-21

सच कहूँ तो, अगर सेवा 99% सिर्फ हमारे देश के भीतर ही चलानी है, तो मुझे लगता है कि इनमें से किसी की भी ज़रूरत नहीं है..

superwoou 2024-06-21

क्या service की सीमा से ज़्यादा, service की प्रकृति और यह देखना कि लागत-दक्षता को कितना महत्व देना है, यही अधिक महत्वपूर्ण नहीं है?

2024-06-21

[यह टिप्पणी छिपाई गई है.]

bus710 2024-06-22

शायद इसलिए कि निर्णय लेने की प्रक्रिया मूलतः vertical होती है, इसलिए “procedural” तरीका ज़्यादा पसंद किया जाता है या अधिक उपयुक्त माना जाता है? अगर हर विभाग और टीम loosely organized हो, तो क्या non-procedural architecture ज़्यादा smoothly काम करेगी, और इसलिए ऐसे queues के applications भी बेहतर चल सकते हैं—यही बात मैं सोच रहा हूँ।

savvykang 2024-06-21

लगता है कि "resume-driven development" ही वह कीवर्ड है जो इस तरह के ट्रेंड को भेदता है।

hyeonseokoh94 2024-06-22

वाह, क्या कमाल की बात है — résumé-driven development...

savvykang 2024-06-23

इसी की एक साथी चीज़ हाइप-ड्रिवन डेवलपमेंट भी है