पूर्व GitHub CTO: "पिछले 10 वर्षों की सबसे बड़ी आर्किटेक्चर गलती full microservices में शिफ्ट होना था"

xguru · 2022-11-17T11:17:01+09:00

"Monolith > apps > services > microservices" पहला, यह कोई नियम नहीं है, बस मेरी राय है। जिन्होंने बड़े पैमाने के distributed systems बनाए हैं, वे जानते हैं कि चीजें वास्तव में बिल्कुल वैसे काम नहीं करतीं, और आपको adapt करना पड़ता है दूसरा, चरण महत्वपूर्ण हैं 5-50 लोगों की कंपनी है तो बस Monolith पर जाएँ 10,000 लोगों की कंपनी है तो ऊपर की सारी चीजें आपके पास होंगी। लेकिन इस बारे में बात करें कि मेरी सोच पहले से कैसे बदली है.. पहले definition से शुरू करें monolith - xyz.com apps - abc.xyz.com services - apps/monolith को support करने वाली चीजें, core infrastructure, core compliance functions, जिन्हें app team ने लिखा हो यह ज़रूरी नहीं (infrastructure team maintain कर सकती है) microservices - कुछ सौ lines of code, ज़्यादातर one-off, जो library या SDK हो सकते/होने चाहिए (could/should) Why? : मूल रूप से "Speed & Risk" की वजह से #1 पूरे development team के लिए एक big app में काम करना ज़्यादा आसान है (मान लें कि पूरी site एक Rails app है) #2 जैसे-जैसे आप बढ़ते हैं, distributed systems तो अनिवार्य रूप से आते ही हैं, और वे अपने आप में ही समझना मुश्किल होते हैं, भले आपके पास सैकड़ों जोखिमभरे microservices न हों #3 अगर आप पूरी तरह micro पर चले जाते हैं, तो अनियंत्रित विस्तार को संभालने के लिए नए concepts लाने पड़ते हैं #4 bespoke infrastructure services या microservices, debt की सबसे चरम अवधारणा हैं। code भी debt है, लेकिन service उसका और भी चरम रूप है। इसका क्या मतलब है, इस पर सोचें। इसे leverage point बनाइए distributed systems engineers duplication पसंद नहीं करते, इसलिए अगर कोई चीज़ कई जगह हो रही हो तो वे सोचते हैं, "इसे बाहर निकालकर एक microservice बना देते हैं" सिद्धांत में यह सही है, और 10-20 तक हों तो ठीक है। लेकिन जब यह दर्जनों से ऊपर चला जाए या बड़ी कंपनी में व्यापक रूप से इस्तेमाल होने लगे, तो यह technical नहीं बल्कि organizational problem बन जाता है जो मैं कह रहा हूँ वह गलत द्विभाजन जैसा लग सकता है, लेकिन वास्तव में microservices के साथ technical challenges भी हैं, और उससे भी अधिक organizational problems हैं मुझे जिन बातों की चिंता है #1 (जब तक किसी IT-background वाले CEO द्वारा नेतृत्व न किया जा रहा हो, जो दुर्लभ है) infrastructure को हमेशा priority में कम महत्व मिलता है #2 बहुत ज़्यादा services होने पर आम तौर पर ownership और boundaries की समस्याएँ पैदा होती हैं #3 ढेर सारे microservices को संभालने के लिए और अधिक tools लाए जाते हैं #4 सबसे महत्वपूर्ण बात, हर वह microservice जिसे library या SDK होना चाहिए था, production में risk पैदा करती है आम तौर पर मेरी सिफारिश #1 जहाँ तक संभव हो, Monolith को जितना लंबे समय तक हो सके बनाए रखें #2 services की शुरुआत infrastructure की ज़रूरतों से करें, app development side से नहीं #3 अगर Mono को तोड़ना ही है, तो उसे छोटे services में नहीं बल्कि बड़े apps में विभाजित करें #4 हर नए app को कंपनी के अंदर एक virtual wall की तरह समझें #5 जहाँ संभव हो, microservices की जगह libraries को प्राथमिकता दें

(twitter.com/jasoncwarner)

46 पॉइंट द्वारा xguru 2022-11-17 | 13 टिप्पणियां | WhatsApp पर शेयर करें

"Monolith > apps > services > microservices"
पहला, यह कोई नियम नहीं है, बस मेरी राय है। जिन्होंने बड़े पैमाने के distributed systems बनाए हैं, वे जानते हैं कि चीजें वास्तव में बिल्कुल वैसे काम नहीं करतीं, और आपको adapt करना पड़ता है
दूसरा, चरण महत्वपूर्ण हैं
- 5-50 लोगों की कंपनी है तो बस Monolith पर जाएँ
- 10,000 लोगों की कंपनी है तो ऊपर की सारी चीजें आपके पास होंगी। लेकिन इस बारे में बात करें कि मेरी सोच पहले से कैसे बदली है..

पहले definition से शुरू करें

monolith - xyz.com
apps - abc.xyz.com
services - apps/monolith को support करने वाली चीजें, core infrastructure, core compliance functions, जिन्हें app team ने लिखा हो यह ज़रूरी नहीं (infrastructure team maintain कर सकती है)
microservices - कुछ सौ lines of code, ज़्यादातर one-off, जो library या SDK हो सकते/होने चाहिए (could/should)

Why? : मूल रूप से "Speed & Risk" की वजह से

#1 पूरे development team के लिए एक big app में काम करना ज़्यादा आसान है (मान लें कि पूरी site एक Rails app है)
#2 जैसे-जैसे आप बढ़ते हैं, distributed systems तो अनिवार्य रूप से आते ही हैं, और वे अपने आप में ही समझना मुश्किल होते हैं, भले आपके पास सैकड़ों जोखिमभरे microservices न हों
#3 अगर आप पूरी तरह micro पर चले जाते हैं, तो अनियंत्रित विस्तार को संभालने के लिए नए concepts लाने पड़ते हैं
#4 bespoke infrastructure services या microservices, debt की सबसे चरम अवधारणा हैं। code भी debt है, लेकिन service उसका और भी चरम रूप है। इसका क्या मतलब है, इस पर सोचें। इसे leverage point बनाइए
distributed systems engineers duplication पसंद नहीं करते, इसलिए अगर कोई चीज़ कई जगह हो रही हो तो वे सोचते हैं, "इसे बाहर निकालकर एक microservice बना देते हैं"
सिद्धांत में यह सही है, और 10-20 तक हों तो ठीक है। लेकिन जब यह दर्जनों से ऊपर चला जाए या बड़ी कंपनी में व्यापक रूप से इस्तेमाल होने लगे, तो यह technical नहीं बल्कि organizational problem बन जाता है
जो मैं कह रहा हूँ वह गलत द्विभाजन जैसा लग सकता है, लेकिन वास्तव में microservices के साथ technical challenges भी हैं, और उससे भी अधिक organizational problems हैं

मुझे जिन बातों की चिंता है

#1 (जब तक किसी IT-background वाले CEO द्वारा नेतृत्व न किया जा रहा हो, जो दुर्लभ है) infrastructure को हमेशा priority में कम महत्व मिलता है
#2 बहुत ज़्यादा services होने पर आम तौर पर ownership और boundaries की समस्याएँ पैदा होती हैं
#3 ढेर सारे microservices को संभालने के लिए और अधिक tools लाए जाते हैं
#4 सबसे महत्वपूर्ण बात, हर वह microservice जिसे library या SDK होना चाहिए था, production में risk पैदा करती है

आम तौर पर मेरी सिफारिश

#1 जहाँ तक संभव हो, Monolith को जितना लंबे समय तक हो सके बनाए रखें
#2 services की शुरुआत infrastructure की ज़रूरतों से करें, app development side से नहीं
#3 अगर Mono को तोड़ना ही है, तो उसे छोटे services में नहीं बल्कि बड़े apps में विभाजित करें
#4 हर नए app को कंपनी के अंदर एक virtual wall की तरह समझें
#5 जहाँ संभव हो, microservices की जगह libraries को प्राथमिकता दें

13 टिप्पणियां

jonnung 2022-11-18

आख़िरी हिस्से में व्यक्त की गई चिंताएँ और सिफारिशें काफ़ी सहमतिजनक लगीं।
दरअसल, कंपनी का आकार हो या सेवा का आकार, संदर्भ काफ़ी मिलता-जुलता है, और ऐसा समय आएगा जब उसे बाँटे बिना काम नहीं चलेगा; उससे पहले उसकी तैयारी करने के लिए बेहतरीन निर्णय क्षमता की ज़रूरत होगी, ऐसा महसूस हुआ।

love7peace 2022-11-17

क्या यह कंपनी के आकार के बजाय सिस्टम के आकार पर निर्भर नहीं होना चाहिए? क्या मैं MSA को गलत समझ रहा था?

ilbanin 2022-11-17

ऊपर की टिप्पणियों में क्या समस्या microservice की नहीं, बल्कि सेवाओं के अनियंत्रित विस्तार की है? इस राय से मैं पहले तो सहमत हूँ, और कंपनी जितनी बड़ी होती जाती है, deployment issues + branch management जैसी monolith की अपनी कमियाँ बहुत साफ़ दिखाई देने लगती हैं, इसलिए लगता है कि cost और productivity के बीच trade-off को अच्छी तरह चुनना होगा।

functor 2022-11-17

बहुत अच्छा लेख है। धन्यवाद।

ruinnel 2022-11-17

मुझे लगता है यह design pattern की अहमियत पर होने वाली बहस जैसी ही बात है।
Design pattern अलग-अलग समस्याओं को हल करने की प्रक्रिया से निकले code patterns होते हैं....
आखिरकार इन्हें स्थिति के अनुसार, ज़रूरत के हिसाब से apply और adapt करना चाहिए.....

लेकिन अक्सर कुछ लोग model answer की तरह design pattern को अनिवार्य मान लेते हैं और उसी में डूब जाते हैं...

आजकल MSA को लेकर भी कुछ ऐसा ही लगता है—काफी लोग ऐसे हैं जो मानो हर हाल में सिर्फ MSA ही सही समझते हैं.

deokim 2022-11-17

यह कुछ-कुछ मुर्गी पहले या अंडा पहले जैसी बात लगती है।
क्या समस्या microservices की नहीं, बल्कि services के बेतहाशा विस्तार की नहीं है?

bbulbum 2022-11-17

मुझे लगता है कि सही balance महत्वपूर्ण है।
जब microservices की ओर जाते हैं, तो इस वजह से कि नई feature = नई microservice बन सकती है,
शायद management धीरे-धीरे और मुश्किल होता जाता है।

hiddenest 2022-11-17

मुझे पहले Segment के tech blog पर आया 'Goodbye Microservices' नाम का लेख याद आ रहा है।
Segment भी CDP होने की वजह से बहुत बड़े पैमाने पर real-time data process करता है, लेकिन इसके बावजूद उसने Microservices से Monolith structure में शिफ्ट किया, और उसके कारणों वगैरह को blog में अच्छी तरह लिखा था। मुझे लगता है कि यह लेख भी उससे कुछ हद तक जुड़ता है :)

https://segment.com/blog/goodbye-microservices/

bamchi 2022-11-17

कुल मिलाकर मैं भी इसी सोच से सहमत हूँ.
हमारी कंपनी में डेवलपर 5 हैं, इसलिए अभी तक monolith (RubyOnRails) को प्राथमिकता देना सही लगता है.
ऊपर के लेख की तरह अगर यह ऐसा प्रोजेक्ट बन जाता है जिस पर 50 से ज़्यादा लोग एक साथ डेवलप करें, तब शायद हम दूसरा monolith विकसित करेंगे.

tnrnfl 2022-11-17

अगर कंपनी में कुल 5-50 लोग हैं, तो बस Monolith के साथ जाएं << मेरा मानना है कि यहां डेवलपर्स की संख्या नहीं, बल्कि कुल कर्मचारियों की संख्या की बात हो रही है, सही?

devstorm 2022-11-17

लगता है यह कंपनी के आकार की बात कर रहे हैं~

yolatengo 2022-11-17

अगर संभव हो तो Monolith को जितना हो सके उतने लंबे समय तक बनाए रखें < इससे पूरी तरह सहमत हूँ। अलग करते समय maintenance cost काफ़ी बढ़ जाती है।

nicewook 2022-11-17

मुझे लगता है कि यह लेख MSA के dogma बनते जाने के खिलाफ एक प्रतिक्रिया के रूप में देखा जा सकता है, और इस मायने में इसका महत्व है।