सरल आर्किटेक्चर के पक्ष में (2022)

• Wave 70 इंजीनियरों वाली $1.7B (2.3 ट्रिलियन KRW) की कंपनी है (अफ्रीका के लिए मोबाइल बैंकिंग सेवा प्रदान करती है)
• यह Postgres-आधारित Python monolith वाले मानक CRUD app आर्किटेक्चर पर बनी है
• सरल आर्किटेक्चर से शुरुआत कर और जटिलता को न्यूनतम रखते हुए समस्याएँ हल करके, इंजीनियर उपयोगकर्ताओं को मूल्य देने वाले काम पर ध्यान केंद्रित कर सके
• Stackoverflow ने एकल monolith को scale करके इतनी सफल वृद्धि की कि उसे $1.8B में अधिग्रहित किया गया

सरल आर्किटेक्चर की दक्षता के बावजूद ज़्यादातर मीडिया जटिल आर्किटेक्चर को पसंद करता है

• tech conferences में जटिल microservices-आधारित आर्किटेक्चर पर बहुत प्रस्तुतियाँ होती हैं, लेकिन सरल monolith पर लगभग कोई प्रस्तुति नहीं होती
• कई कंपनियाँ छोटे पैमाने के applications होने के बावजूद जटिल technologies की नकल करती हैं और उसी से conferences तथा HN पर लोकप्रियता पाती हैं
• हमारा इस्तेमाल किया जाने वाला आर्किटेक्चर इतना सरल है कि architecture diagram बनाने की भी ज़रूरत नहीं पड़ती

सरलता बनाए रखने के तरीके

• Wave synchronous Python का उपयोग करता है, जिसका मतलब है कि server process I/O का इंतज़ार करते समय block हो जाता है
• Eventlet जैसे asynchronous frameworks आज़माए गए, लेकिन उनमें इतने bugs थे कि उनकी लागत operational pain के लायक नहीं लगी
• जटिलता बढ़ाने के बजाय, जिन कामों का execution time लंबा होता है उन्हें queue में अलग करके संभाला जाता है
• data residency नियमों का पालन करने के लिए कुछ देशों में on-premise data centers चलाने पड़ते हैं
  • सेनेगल/कोट द’ईवोआर cloud पर थे, लेकिन युगांडा और अन्य देशों में नियमों के कारण on-premise की आवश्यकता थी
  • ऐसे समय में जटिल आर्किटेक्चर की तुलना में सरल आर्किटेक्चर कहीं अधिक आसान होता है

खरीदने के बजाय खुद बनाना

• छोटी टीम होने के कारण शुरुआत में software खरीदना पसंद था, लेकिन जब गंभीर bugs ठीक नहीं किए जा सके तो अपने tools विकसित किए गए
• अपने tools बनाना ऐसी जटिलता है जिसे हम उठाना नहीं चाहते, लेकिन कुछ product categories में व्यापक शोध के बाद भी ऐसा vendor नहीं मिला जो हमारे लिए उपयुक्त product दे सके
• core competency के बाहर भी कभी-कभी अपने tools बनाना और internal expertise बनाए रखना ज़रूरी होता है

जिन चुनावों पर पुनर्विचार है

• RabbitMQ, Celery, SQLAlchemy, Python जैसी technology choices पर पुनर्विचार किया जा रहा है, क्योंकि ये जटिलता बढ़ाती हैं या maintenance burden बढ़ाती हैं
• अगर नया codebase शुरू करना हो, तो इन technology choices पर बहुत सावधानी से विचार किया जाएगा

जिन चुनावों से संतुष्टि है

• GraphQL, custom transport protocol, Kubernetes जैसी choices से संतुष्ट हैं
• GraphQL के फायदे हैं जैसे self-documentation, code generation, GraphiQL interactive explorer आदि
• GraphQL के उपयोग में इसके फायदे नुकसान से अधिक माने जाते हैं
  • फायदे
    • सटीक return types के लिए self-documentation
    • सटीक return types के code generation के कारण client अधिक सुरक्षित हो जाते हैं
    • GraphiQL interactive explorer से productivity में सुधार
    • अलग-अलग apps (user app, support app, Wave agent app आदि) ज़्यादातर एक ही API साझा कर सकते हैं, जिससे जटिलता घटती है
    • configurable query language का उपयोग करने पर clients बिना बहुत से special-purpose endpoints बनाए, एक ही packet round trip में अपनी ज़रूरत का सटीक data ला सकते हैं
    • RESTful API में क्या माना जाए, इस पर होने वाली bikeshedding (महत्वपूर्ण मुद्दों को टालकर कम महत्वपूर्ण बातों पर लंबी बहस करना) समाप्त होती है
  • नुकसान
    • जब GraphQL अपनाया गया था, उस समय GraphQL libraries बहुत अच्छी नहीं थीं
    • default GQL encoding दोहरावपूर्ण है, और चूँकि कई ग्राहक low bandwidth का उपयोग करते हैं, इसलिए size limits पर बहुत ध्यान दिया जाता है
• Kubernetes का उपयोग देश-वार data center संचालन आवश्यकताओं को पूरा करने के लिए किया जाता है

निष्कर्ष

• application architecture को जितना संभव हो उतना सरल रखकर, जटिलता (और manpower) का budget वहाँ खर्च किया जा सकता है जहाँ वह business के लिए मददगार हो
• जब तक जटिलता जोड़ने का कोई मजबूत कारण न हो, काम को यथासंभव सरल तरीके से करने की सोच के कारण, हम अफ्रीका के financial business जैसे सामान्यतः कठिन माने जाने वाले क्षेत्र में काम करते हुए भी बहुत अधिक इंजीनियरों के बिना काफ़ी बड़ा business बना सके

[secret3056]

"build के बजाय buy" की जगह शायद "buy के बजाय build" सही लगता है।

Another area is with software we’ve had to build (instead of buy).

[xguru]

आह, मैं ज़ोर देने की कोशिश कर रहा था, लेकिन शीर्षक अजीब हो गया था। मैंने उसे ठीक कर दिया है। धन्यवाद।

[savvykang]

क्या यह आर्थिक चक्र के हिसाब से बदलने वाला ट्रेंड है? ट्रेंड से अलग, monolith से शुरुआत करना fixed cost घटाने और maintenance के लिहाज़ से फ़ायदेमंद है

[aer0700]

समझने में आसान architecture को maintain करना भी आसान होता है।

[mhj5730]

मेरे हिसाब से किसी भी service को monolithic तरीके से शुरू करना बेहतर लगता है। अगर शुरुआत से ही MSA लेकर चलें, तो वह पैसों की बर्बादी है।

[dhlee0305]

"जटिलता बढ़ने पर लागत (पैसा, लोग, समय...) भी बढ़ती है"
"जिस समस्या को सरल architecture से हल किया जा सकता है, उसे जटिल architecture से हल करने की कोशिश मत करो."

[xguru]

Hacker News राय

• microservices पर एक engineer की सलाह

  • microservices performance सुधारने की strategy नहीं हैं, बल्कि संभावित cost reduction strategy और engineering coordination strategy हैं।
  • horizontally scalable monolithic application और microservices के बीच बहुत बड़ा अंतर नहीं है, सिवाय उन मामलों के जहाँ आप किसी खास feature को scale down करना चाहते हों।
  • monolithic app में app के सिर्फ एक हिस्से को scale down करना संभव नहीं होता।
  • cost reduction बड़े scale पर शुरू होता है, और इसके लिए कम-से-कम 3 replicas चाहिए।
  • ज़्यादातर companies में असली फ़ायदा engineering coordination में होता है।
  • single repository वाले monolith को एक team own और manage कर सकती है, लेकिन shared monolith में कोई भी ownership नहीं लेता, इसलिए उसे manage करना मुश्किल हो जाता है।

• microservices पर एक talk

  • general tech conferences में microservices architecture की complexity और side effects पर कई presentations हुईं, लेकिन simple monolith बनाने पर कोई presentation नहीं थी।
  • David Schmitz की microservices failure tips पर आधारित talk प्रभावशाली थी, और उनका humorous presentation style काफ़ी आकर्षक है।

• cognitive bias और simplicity

  • लोग अक्सर किसी चीज़ को जोड़ने पर ध्यान देते हैं और simple solution को नज़रअंदाज़ कर देते हैं।
  • research दिखाती है कि Lego संरचनाओं में ईंटें जोड़ने के बजाय उन्हें हटाकर समस्या हल करना बेहतर solution हो सकता है।

• over-engineering और अनुभव की कमी

  • architecture को "काफ़ी simple, लेकिन ज़रूरत भर complex" होना चाहिए, लेकिन इसे हासिल करने के लिए experience चाहिए।
  • IT industry में अक्सर experience की कमी होती है, और experience पाने में समय लगता है।
  • कम experience वाले engineers और managers अक्सर अनावश्यक technologies या metrics का इस्तेमाल करते हैं।

• work-life balance को महत्व देने वाली company

  • ऐसी company की तलाश है जो product improvement पर focus करे और बाकी समय personal life के लिए छोड़े।

• Dan Luu के बारे में व्यक्तिगत अनुभव

  • Dan Luu अपने blog के fans से बातचीत में उदार हैं और software तथा hardware की सीमा-रेखा पर गहरी expertise रखते हैं।
  • वे अपनी insights और expertise खुलकर साझा करते हैं, और उनसे सीखना बहुत सुखद अनुभव है।

• simple architecture का महत्व

  • ज़्यादातर मामलों में ज़रूरी architecture में SSL-enabled load balancer, कई app servers, sharded database, message queue जैसे बुनियादी components शामिल होते हैं।

• architecture और engineering team की social structure

  • architecture को engineering team की social structure को reflect करना चाहिए; इसे नज़रअंदाज़ करने पर confusion और inefficiency पैदा हो सकती है।
  • बड़े monolithic repository और simple architecture को manage करना मुश्किल हो सकता है, और Google तथा Meta जैसी companies भी अंदरूनी तौर पर बहुत से tools बनाती हैं।
  • architecture teams के बीच collaboration को support भी कर सकता है और बाधित भी, इसलिए technical leadership को इसे ध्यान में रखना चाहिए।

• simple architecture की preference

  • simple architecture और monolith ज़्यादातर मामलों में उपयुक्त हैं, लेकिन synchronous IO से पैदा होने वाली समस्याओं से बचने के लिए सावधान रहना चाहिए।
  • data integrity bugs financial systems में बचने लायक एक महत्वपूर्ण समस्या हैं।

[dangyup]

क्या आप कृपया "David Schmitz के माइक्रोसर्विस विफलताओं पर सुझावों को कवर करने वाले व्याख्यान" लिंक साझा कर सकते हैं?

[xguru]

यह https://www.youtube.com/watch?v=r8mtXJh3hzM है