हाल ही में मैंने विदेश के एक टेक ब्लॉग पर चर्चा में रहे "Microservices Killed Our Startup. Monoliths Would’ve Saved Us" शीर्षक वाले लेख को पढ़ा। उसकी बात इतनी चुभने वाली और साथ ही relatable लगी कि उसका सार साझा कर रहा हूँ。
यह बिना सोचे-समझे नई टेक्नोलॉजी अपनाने के ख़तरे को दिखाने वाली एक बेहतरीन "गलतियों की नोटबुक" जैसी लगती है।
1. शुरुआत: "हम भी Netflix की तरह करते हैं"
- स्थिति: $2.5M की seed investment, मासिक revenue में 40% growth, 50,000 users। Rails monolith पर बहुत अच्छी तरह चल रहा startup।
- समस्या की शुरुआत: lead architect आया और "Scalability" का नारा देते हुए MSA migration का प्रस्ताव रखा।
- तर्क: "अभी की structure में coupling बहुत ज़्यादा है। Netflix और Uber को देखो। अगर हमें भी उनकी तरह बनना है, तो microservices पर जाना होगा।"
- हकीकत: 4 developers और 1 DevOps वाले team ने Netflix architecture अपनाने का फ़ैसला कर लिया।
2. नर्क जैसे 6 महीने (MSA adoption timeline)
[पहला महीना: honeymoon]
- notification service को अलग करने में सफलता। "देखा! बढ़िया चल रहा है, है न?" कहते हुए जश्न मनाया।
- लेकिन deployment time बढ़ना, repositories बढ़ना जैसी शुरुआती चेतावनियाँ शुरू हो गईं।
[दूसरे~तीसरे महीने: दरार की शुरुआत]
- billing service को अलग किया गया। यह users, inventory, और order services — सबसे जुड़ा हुआ था।
- नतीजा: network latency की वजह से response time 200ms → 800ms तक धीमा हो गया। एक service बंद होती तो chain failure से पूरा system ठप हो जाता।
[चौथे~पाँचवें महीने: distributed transactions का दुःस्वप्न]
- monolith में जहाँ एक DB transaction से काम हो जाता था, distributed environment में Saga pattern तक लाना पड़ा।
- inventory कम हो गई, payment fail हो गया, rollback उलझ गया... data inconsistency की वजह से CS requests की बाढ़ आ गई।
- एक साधारण column जोड़ने के लिए 6 services छूनी पड़ती थीं, इसलिए 2 घंटे का काम 3 दिन लेने लगा।
[छठा महीना: टीम का टूटना]
- developers feature development के बजाय अपना सारा समय infra management में लगाने लगे।
- infra cost $3,000 → $12,000 (4 गुना उछाल)।
- core developer ने इस्तीफ़ा दे दिया ("मैं यहाँ product बनाने आया था, पूरा दिन Kubernetes से जूझने नहीं")
3. फैसला: "हम Netflix नहीं हैं"
architect अब भी कह रहा था, "service mesh लाते हैं और monitoring tools बढ़ाते हैं", लेकिन लेखक फट पड़ा।
> "हम Netflix नहीं हैं! Netflix में 500 engineers हैं, और हम सिर्फ 4 हैं!"
आख़िरकार architect ने कंपनी छोड़ दी, और team ने monolith पर वापस जाने (rollback) का फ़ैसला किया।
4. monolith में वापसी, और पुनर्जीवन
- 8 हफ्तों में code को फिर से monolith में जोड़ा गया।
- नतीजा:
- feature release speed वापस आई (महीने में 4 → 20)
- response time 220ms पर स्थिर हुआ
- infra cost कम हुई
- और सबसे बढ़कर developers की खुशी बढ़ी
5. मुख्य सीख (इस लेख का निष्कर्ष)
- MSA 'तकनीकी समस्या' नहीं, बल्कि 'organizational problem' सुलझाने का टूल है।
- इसका इस्तेमाल तब होता है जब developers 50+ हों और वे एक-दूसरे के काम पर चढ़ रहे हों, या deployment cycles बहुत अलग-अलग हों।
- Netflix/Google आपके role model नहीं हैं।
- वे भी शुरुआत में monolith थे। scale बढ़ने पर उन्होंने बदलाव किया, शुरू से ऐसा नहीं था।
- complexity एक tax है।
- हर नई service के साथ management cost compound interest की तरह बढ़ती है।
- network calls मुफ़्त नहीं होतीं।
- in-memory function call (nanoseconds) और network call (milliseconds) में ज़मीन-आसमान का फ़र्क है।
एक पंक्ति में सार:
"monolith दुश्मन नहीं है। बुरी architecture दुश्मन है। 4 लोगों की team हो तो कृपया बस monolith ही इस्तेमाल करो।"
14 टिप्पणियां
लो, अब MSA के कट्टर समर्थक उमड़ पड़ेंगे।
यह सही बात है कि network calls मुफ़्त नहीं होते। function call और API call वाकई अलग होते हैं।
मैं यहाँ प्रोडक्ट बनाने आया हूँ, दिन भर Kubernetes से छेड़छाड़ करने नहीं —> यह मैंने सुनी सबसे बेवकूफी भरी बात है
क्यों? अगर स्थिति ऐसी है कि k8s सिर्फ़ k8s के लिए ही किया जा रहा है, तो यह बात सही लगती है, है ना?
मुझे bungker की टिप्पणियाँ पसंद हैं, इसलिए मैं उन्हें एक-एक करके क्लिक करके पढ़ता हूँ, लेकिन इस बात से मैं सहमत नहीं हो पा रहा हूँ, हूँ। क्या आप थोड़ा और विस्तार से समझा सकते हैं?
यह बिना सार वाला AI पोस्ट है, इसलिए आजकल मैं Medium लगभग देखता ही नहीं हूँ
अगर यह 4 लोगों द्वारा बनाई गई service है, तो लगता है कि इसे MSA में बाँटने की कोई वजह नहीं थी।
MSA करने के लिए संगठन को भी MSA के हिसाब से ढालना पड़ता है...
मुझे लगता है कि नीचे दिए गए सारांश में 4वें बिंदु का असली मतलब शायद यही है। और कुल मिलाकर, सामग्री खुद भी काफ़ी relatable लगी।
उम्... कुछ अजीब सा लग रहा है
लगता है यह लेख AI से लिखा गया है।
मुझे भी आजकल यह बात काफी महसूस हो रही है..
मुझे लगता है कि कई ब्लॉग पोस्ट शायद लेखक के अपने अनुभव + AI की मदद लेकर
लिखी जा रही हैं।
क्योंकि बहुत-सी लिखाइयाँ इतनी तार्किक और पढ़ने में आसान होती हैं।
मैं जो कहना चाहता था, वह यह है कि यह काफ़ी AI-जैसा लगता है और इसमें कोई reference भी नहीं है, इसलिए मेरी राय है कि ऐसी पोस्ट साझा नहीं करनी चाहिए।
यह Hacker News पर पोस्ट किया गया लेख है। मैं जो ज़्यादातर लेख पोस्ट करता हूँ, वे Hacker News पर आए हुए होते हैं.
https://news.ycombinator.com/item?id=46469845
जैसा आपने कहा.. लगता है कि मुझे Hacker News रेफ़रेंस भी जोड़ना चाहिए।
1) लेख की विश्वसनीयता पर शक: इसमें marketing/AI-generated कंटेंट जैसी गंध आती है
सार
तथ्यात्मक तीखा उद्धरण (अनुवाद)
एक-पंक्ति टिप्पणी
2) leadership/architect पर आलोचना: समस्या technology नहीं, ‘decision-making structure’ थी
सार
चुभता हुआ उद्धरण (अनुवाद)
एक-पंक्ति टिप्पणी
3) business नज़रिया: क्या startup की नाकामी की असली वजह सच में MSA थी?
सार
तथ्यात्मक तीखा उद्धरण (अनुवाद)
एक-पंक्ति टिप्पणी
4) तकनीकी insight: monolith vs MSA पर experience-based सलाह (यही हिस्सा सच में काम का था)
सार
चुभता हुआ उद्धरण (अनुवाद)
एक-पंक्ति टिप्पणी
“monolith से शुरू करो, और services को तभी अलग करो जब boundaries ‘स्वाभाविक’ रूप से उभरें.”
community की कुल राय, एक वाक्य में
ज़्यादातर लोग “हम Netflix नहीं हैं” वाली बात से सहमत थे, लेकिन साथ ही यह शक भी काफ़ी मज़बूत था कि “यह लेख खुद Netflix-रोग बेचने वाली narrative (= marketing/AI) भी हो सकता है.”