लगभग काम न करने वाले आकर्षक सिस्टम आइडियाज़

लगभग काम न करने वाले सिस्टम आइडियाज़

• "बस इसे प्लग-इन करने लायक बना दो"

  • जब एक implementation काम नहीं करता, तो उद्देश्य होता है कि डेवलपर्स नए implementation को आसानी से जोड़ सकें। लेकिन अधिकतर मामलों में API जो फीचर देता है, वह उतना आसान नहीं होता। वास्तविक प्लग-इन क्षमता के लिए दूसरा implementation शुरुआत से ही साथ डिज़ाइन करना पड़ता है।

• "बस एक API जोड़ो"

  • प्लेटफॉर्म बनाने और डेवलपर्स को आकर्षित करने के लिए API जोड़ने के कई मौके आते हैं। लेकिन API देने का मतलब यह नहीं कि लोग उसे इस्तेमाल करेंगे। compatibility और interoperability के लिए लगातार प्रयास की जरूरत होती है, और API देने से यह निश्चित नहीं होता कि उपयोगकर्ता ज़रूर आएंगे। प्लेटफॉर्म बनाना एक गंभीर business है, और सिर्फ API देने से ही आर्थिक आधार बनाना मुश्किल होता है।

• "बस एक बार और abstract कर लो"

  • कंप्यूटर विज्ञान में कहा जाता है कि किसी समस्या का समाधान और अधिक अप्रत्यक्ष रेफरेंस (indirection) से मिल सकता है। लेकिन बहुत जल्दी abstraction जोड़ने से maintenance, security और performance optimization में मुश्किलें बढ़ सकती हैं। बिना योजना के जोड़ा गया अतिरिक्त abstraction code maintain करना कठिन बना देता है।

• "बस इसे async कर दो"

  • Asynchronous programming कंप्यूटर साइंस का लंबे समय से शोध क्षेत्र रहा है। web frameworks ने इसे अच्छी तरह abstract किया है, लेकिन framework के बाहर खुद async को manage करने की कोशिश में अनपेक्षित bugs का जोखिम बढ़ जाता है।

• "access control बाद में जोड़ेंगे"

  • सिस्टम सिक्योरिटी शुरुआत से ही डिज़ाइन में होनी चाहिए, लेकिन time-to-market के दबाव में अक्सर बाद में जोड़ी जाती है। ग्राहक और attacker दोनों के नजरिए से शुरुआत से ही यदि access control पर काम न किया जाए, तो बाद में product को फिर से design करना पड़ सकता है।

• "डेटा को sync कर दो"

  • डेटा सिंक्रोनाइज़ेशन एक बहुत कठिन समस्या है, जिसे केवल अनुभव से ही ठीक से समझा जा सकता है। डेटा सिंक्रनाइज़ेशन पर आधारित solution बनाना लगभग कभी सही विकल्प नहीं होता।

• "cross-platform बना दो"

  • cross-platform निर्माण ऑपरेटिंग सिस्टम, क्लाउड प्रोवाइडर या browser बनाने जैसा ही है। जब प्लेटफॉर्म नया हो या application सरल हो, तब यह चल सकता है, लेकिन समय के साथ यह काम कठिन होता चला जाता है।

• "native में escape hatch दे दो"

  • cross-platform की सीमाएँ होने पर सामान्य रूप से native फीचर में निकलने का रास्ता देना उपयोगी लगता है। लेकिन यह तरीका framework द्वारा maintain किए गए state से टकरा सकता है, और 10 में से करीब 9 बार असफल हो जाता है।

• निष्कर्ष

  • ये approaches हमेशा विफल नहीं होतीं, लेकिन ज़्यादातर मामलों में बेहतर तरीका मौजूद होता है। बुनियादी principles पर भरोसा करके समस्या हल करना और failure-prone software patterns से बचना ज़रूरी है।

[ndrgrd]

प्लग के मामले में सबसे ज़रूरी बात यह है कि इंटरफ़ेस को डिज़ाइन करते समय केवल अनिवार्य व्यवहारों को जितना संभव हो उतना छांटकर रखा जाए.
अगर इंटरफ़ेस को बस मौजूदा कोड की मोटी-मोटी संरचना उठाकर बना दिया जाए, तो वह स्वाभाविक रूप से उस implementation से बंधा हुआ एक अनावश्यक इंटरफ़ेस बन जाता है, लेकिन ऐसे मामले वाकई बहुत आम हैं...

[GN⁺]

Hacker News राय

• DSLs और API अक्सर सफलतापूर्वक काम करते हैं। TensorFlow जैसे inference engine को भी DSL या DSL को wrap करने वाले API के रूप में देखा जा सकता है

  • SQL, Shader language, BPF आदि को भी इसी तरह के उदाहरण माना जा सकता है
  • "चलो बस API जोड़ देते हैं" वाला approach सफल नहीं हो सकता। UI implement करते समय जैसे सावधानी और गहराई से काम करना पड़ता है, वैसे ही यहाँ भी करना चाहिए

• DSLs कभी-कभी बेहतरीन ढंग से काम करते हैं। इसके लिए jOOQ.org देखा जा सकता है

• Elastic Load Balancer workload पर प्रतिक्रिया देने वाला control loop है। यह एक तरह का commodity है

• ज़्यादातर industries में resource shortage व्यापक है। संबंधित सामग्री के लिए erikbern.com और "Goal: Process of Ongoing Improvement" को देखा जा सकता है

• anomaly detection distributed systems की समस्या नहीं है। लेकिन जिन लोगों ने यह समस्या झेली है, वे इसे ज़रूरी मान सकते हैं

  • Isolation Forest algorithm कभी-कभी चमत्कारिक साबित होता है। 2018 में text पर CNN-आधारित embedding का उपयोग करके अच्छे नतीजे मिले थे

• यहाँ "लगभग" शब्द प्रभावी नहीं है। यह सिर्फ़ निराशावाद और निंदकता है

• बहुत से लोग exceptions के लिए कोई सूक्ष्म decision function ढूँढने की कोशिश करते हैं। लेकिन वास्तव में बात सरल है। मैं करूँ तो ठीक चलता है, और पिछला व्यक्ति करे तो ठीक नहीं चलता

• "Domain Driven Design" के अनुसार business structure के हिसाब से application design करना आपदा का नुस्खा है

  • छोटे business में शायद समस्या न हो, लेकिन सफल या बढ़ते business में इसका पछतावा तुरंत हो सकता है
  • इसके बजाय functional layers के इर्द-गिर्द design करें, और जहाँ तक संभव हो business logic को configuration, database rows, और user workflow में बनाए रखें

• load-responsive control loop बुनियादी और आवश्यक building block है। इसका उपयोग कई systems में होता है

• मैंने कई DSLs, P2P cache, और hybrid parallelism इस्तेमाल करने वाले projects पर काम किया है, और उनमें से ज़्यादातर सफल रहे

  • P2P cache की ज़रूरत नहीं थी, इसलिए उससे कोई बड़ा लाभ नहीं मिला
  • यह जटिल है, लेकिन यही जटिलता ऐसे features देती है जिन्हें किसी और तरीके से हासिल करना मुश्किल है

• "बस data sync कर देते हैं" वाला approach समस्याएँ पैदा कर सकता है

  • कई systems को "internet scale" को लक्ष्य बनाकर design किया गया था, लेकिन वास्तव में वे उस स्तर तक पहुँचते ही नहीं हैं
  • ऐसी teams या तो भोली होती हैं, या बदतर स्थिति में non-engineering managers का उपयोग करके समस्या सुलझाने के लिए funding खर्च करती हैं

• मैंने इनमें से कई ideas को सफलतापूर्वक लागू किया है। इसलिए यह थोड़ा अजीब पढ़ाई देता है